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The  symmetry  and  simplicity  of  the  lambda  calculus  sets  a 
standard  against  which  all  languages  can  be  compared.  For 
instance,  the  essential  equivalence  between  formal  parameters  and 
declarations  in  the  lamoda  calculus  suggests  a  solution  to  many 
problems  of  language  design.  This  has  been  used  in  several 
experimental  languages,  e.g.  Quest. 

Although  the  lambda  calculus  is  capable  of  computing  any 
computable  function,  it  provides  a  model  of  computation  that  is 
much  closer  to  real  languages  than  most  other  such  models  (e.g. 
Markov  algorithms,  Turing  machines,  recursive  functions).  It  is 
therefore  more  relevent  to  the  real  problems  of  language  design. 

The  programming  practices  and  modes  of  thought  used  with  the 
lambda  calculus  and  its  derivatives  (such  as  LISP)  have  formed 
the  foundation  of  f unct  i  o  nal  programmi  ng  -  the  method  of  program- 
ming recently  popularized  by  Backus  and  characterized  by  a  high- 
level  applicative  programming  style.  The  lambda  calculus  is 
essential  for  an  understanding  of  the  design  and  implementation 
of  such  1 anguages . 


1.2   The  Lambda  Calculus 


1.2.1   calculus  define^ 
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1.2.2   bound  variables  defined . 

One  of  the  central  ideas  of  the  lambda  calculus 
bound   variable  (sometimes  called  a  dummy  var  iable)  . 
ables  are  common  in  all  mathematical  notations,  for 
the  summation 


is  that  of  a 

Bound  vari- 

instance,   in 


i  =  l  x 


the 


is  the  bound  variable.   It  is  a  characteristic   of   bound 
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variables  that  it  doesn't  natter  what  thev  are.   ^or  instance, 

k=l  K 

neans  exactly  the  sane  thing  as  the   previous   summation.    Simi- 
larly, the  integral  of  x~-3x  with  resoect  to  x: 

Tx2-3x  dx 
T) 

is  the  same  as  the  integral  of  u  -3u  with  resoect  to  u: 

Pu2-3u  du 
T) 

In  set  theory,  the  set  of  all  x  such  that  x^>0  is  the  same  as   the 
set  of  all  n  such  that  n> n : 

{x!x>0}  =  {n!n>0} 

Also,  a  proposition  such  as  "tor  every  x,  x+l>x": 

¥x{  x+l>x  } 
is  the  same  as  the  oroposition  "tor  every  y,  y+l>y": 

¥y{  y+l>y  } 

In  the  following  examnles  the  bound  variables  are  listed   on   the 
r  ight . 
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Expression 


Bound 
Variable 


Verbalization 


1  =  1 

i 

the 

sum  tor  i  from  1  ... 

.ft  f(1) 

1  =  1 

i 

the 

oroduct  for  j  from  1  ... 

d  (x2-3x)/dx 

X 

the 

derivative  with  resDect  to  x  of 

nv(y2-3y) 

y 

the 

derivative  with  resoect  to  v  of 

t  0 

Txz-3xdx 
T3 

X 

the 

integral  with  respect  to  x  of 

{  x  !  x>0  } 

X 

the 

set:  of  all  x  such  that 

Vx{  X+l>x  } 

X 

tor 

all  x , 

3y(  2y=y  } 

y 

there  exists  a  y  such  that 

<=x .  x>y 

X 

any 

x  such  that 

?y.?y=l 

y 

the 

uniaue  y  such  that 

1.2.3   bound  and  free  occurrences,  and  scoos 


Two   ideas   that   will   be   very   useful   to   us   are   bound 
occurrence  and  free  occurrence.   Consider  the  exDression 


£a 

1  =  1 


n 


The  occurrence  of  'j'  in  'A^'  is  called  a   bound   occurren< 
the   variable   'j'.    It   is  bound  bv  the  summation  operato; 


ice  of 
1'.  It  is  bound  by  the  summation  operator  (l)  , 
which  is  called  the  bind  inq  site  (or  just  binding )  of  this 
occurrence  of  'i*.  we  can  see  that  'j'  is  bound  by  noting  that 
we  can  change  it  to  any  other  variable  (except  'i')  without 
changing  the  meaning  of  the  expression.   ^or  instance, 


El 
i   *-  A, 


k  =  l 


ik 


Any  occurrence  of  a  variable  that  is  not  a  bound  occurrence  is 
called  a  free  occurrence.  For  instance,  'i',  '  n  '  and  'A1  all 
occur  free  in  tue  above  expression.  Clearlv,  if  we  change  a  free 
variable  we  have  changed  the  meaning  of  the  expression: 
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5m 

i  =  l 


i] 


Notice  that  when  we  say  that  an  occurrence  of  a  variable  is  bound 
or  tree,  we  say  this  relative  to  some  expression.  por  instance, 
; j '  is  tree  in 


but  is  bound  in 


n 


1  =  1  i] 


and 


Similarly,  'i'  is  free  in  the  above  expressions,  but  bound  in 


0L 
i  =  l 


D. 

3=1   J 


which  is  the 
bound.   This 


The  bindinq  site  of  a  variable  determines  its  scope , 
region  of  the  expression  over  which  that  variable  is 
region  is  usually  indicated  by  some  textual  convention, 
brackets  or  Darentheses.  To  state 
occurrences  of  a  variable  which  are  in  the  scoDe  of  a  bindina  of 
that  variable  are  bound  occurrences  of  that  variable.  The  fol- 
lowing figures  exemnlitv  these  conceots: 


such 
things   differently,   a 


as 


binding 
site  of  x 


scope  of 
■ 


!  x>y  } 

/    % 


bound 


ree  occurrence  ot  y 
occurrence  of  x 


binding 

site  of  : 


scoDe 


tree  occurrence  ot  y 
bound  occurrences  of  x 


As  we  have  already  seen,  it  is  perfectly  meaningful  for  scopes  to 
be  nested  within  other  scopes.  Some  examples  of  nested  scopes 
are  shown  below  (the  brackets  indicating  scooe  are  called  scoping 
lines)  : 
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>- 

i=l 


(i  §.  *< 


j  =  l 


ii) 


— i — 

scooe  of  i 
1 


scooe  ot  1 

?x  rv  +xv  dv  dx 


scooe  ot  y 
j 


scope  ot  x 
We  can  summarize  these  ideas  as  follows: 

*  The  binding  site  of  a  variable  determines  its  scope . 

*  An  occurrence  of  a  variable  is  bound  if  it  is  in   the   scooe 
of  a  binding  site  of  that  variable. 

*  An  occurrence  of  a  variable  is  free  otherwise. 
EXERCISES; 

For  each  variable  occurrence  in  the  following  expressions, 
indicate  whether  it  is  a  binding  site,  a  bound  occurrence,  or  a 
free  occurence.  Draw  scooing  lines  to  indicate  the  scooe  of  each 
binding . 

1.   {  n  I  n>m  } 


2  .   Tx  sin  fx/v)  dx 

V) 

1  x 
3.   rxTsin(yx)dy  dx 

7)   T) 


OT^V 


x2+y2 
xv  . 


i=lj=l  ^  3i 


*x[x«7  =>  3y  (yeZ  A  X=v+1  )  1 


7.   {xlx>0}  u  (x|x<0) 


{xlx^O} 


8.   sinh(x) 


,*--•** 
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I . ?  . d   renaming  bound  var  iables . 

As  we  have  seen,  bound  variables  are  arbitrary.  This  is  one 
reason  they  are  often  called  dummy  variables;  they  only  serve  to 
establish  a  connection  between  parts  of  an  expression.  Bound 
variables  are  the  oronouns  on  mathematics. 


Changing  a  bound   variable   to 
chanqe  the  meaning  of  an  expression 


a 
i-l  1] 

both  mean  the  sum  of  the  j-th 
change  the  bound  variable  to 


and 


column 


another   variable 
For  instance, 

of  the  matrix  A. 


does   not 


Suooose  we 


1 


2  , 


This  sums  the  diagonal  of  the  matrix;  we  have  altered  the  meaning 
of  the  expression!  We  got  into  this  trouble  because  we  changed 
the  bound  variable  'i1  to  the  variable  ']',  which  already 
occurred  within  the  expression.  Thus,  the  occurrence  of  ' j'  in 
A-j  became  accidently  bound.  This  is  called  a  collision  of  vari- 
ables . 


The  conclusion  that  can  be  drawn  from  this  is:  we  can 
change  a  bound  variable,  throughout  its  scope,  to  another  vari- 
able only  if  the  latter  variable  does  not  occur  within  that 
scope. 


EXEPCTSFS 


For  each  expression  determine  whether  the   indicated   change 
of  variable  alters  the  meaning  of  the  expression. 

1.  fx!x>y};   change  x  =>  z. 

2.  {x!x>y};   change  x  =>  y. 

3.  gL(x3-xy) ;   change  x  =>  t. 

4.  same;   change  x  =>  y. 

5.  ¥x[3y (y>x) 1 ;   y  =>  x. 
;   v  =>  x. 

x   —x 

7.   sinh(x)  =  e  "*.f ;   x  =>  u. 


<ixOv 


?j.  2 
x  -+vz 


xy 
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«.   {m!m>el  U  {el  sin(e)=0  >;   e  =>  m. 
9.   {x  lx>0}  u  {y  |v<0} ;   v  =>  x. 

i  =>  j. 


10.     ?  A  •  +   §*  R  ^ 


i  =  l 


j=l 


i' 


11. 


>  i-  >  vj;   ]  =>  i. 

1=1   3=1  J 


1.2.5   function  definition . 

™hen  bound  variables  are  used 
are  often  called  formal  parameters 

f(x)   = 


in  function   definitions   they 


For  examole,  in 


2^ 


3x 


'x'  is  the  bound  variable  or  formal  oarameter.  This  is  different 
from  the  previous  examples  of  bound  variables  in  that  the  bound 
variable  and  the  function  name  are  tied  toaether.  ^he  lambda 
calculus  orovides  a  notation  for  functions  which  does  not  have 
this  problem.  For  instance,  in  the  lambda  calculus  the  function 
f  can  be  written 


>x{x?-3x} 


(the  X    is 
anv 


a  lambda),  which  can  be  read  "that  function  which  takes 
x  into  x  *3x."  In  the  lambda  calculus,  if  we  have  defined 


=  ,\x{x2-3x} 


and  then  we  ask  the  value  of  'f(5)',  we  can  find  it  by  substitut- 


ing  '  5  '   for 
start  with 


x'   throughout   its  scone 


f  (5) 


'ore  specifically,  we 


when  we  substitute  Ax{x2-3x}  for  'f '  we  get 

>x{x2-3x} (5) 

Now,  we  replace  this  expression  by  a  cooy  of  the  body  of  f 
(namely  x2-3x)  in  which  everv  free  occurrence  of  'x'  is  reolaced 
bv  '5' : 


5^-3-5 


25-15 


in 


This  is  called  the  "cony  rule"  for  function  evaluation  because 
the  invocation  'f(5)'  is  actually  replaced  by  a  cooy  of  the  body 
of  the  function  with  its  parameter   textuallv   substituted,   i.e. 
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'5z-3*5'. 

1.2.6   syntax  ol  the  xambda  caicuius . 

The  lambda  calculus  has  a  very  simple  syntax.  Lambda 
expressions  are  composed  or  the  symbols  '/ '  ,  ' { '  ,  ' }  '  ,  '  (  '  ,  '  )  * 
and  variable  names,  put  together  according  to  the  toiiowing 
r  uies : 


(1)  In  'x'  is  a  variable  and  'E'  is  an  expression  or  the 
lambda  caicuius,  then  '/x{E}'  is  an  expression  on  the  lambda  cal- 
culus, called  an  abstraction.  We  call  'x*  the  binding  or  the 
abstraction  and  'E1  the  body  oi  the  abstraction. 

(2)  Ir  'P*  and  'E1  are  expressions  ol  the  lambda  caicuius, 
then  'F(E) '  is  an  expression  ol  the  lambda  caicuius,  called  an 
appl ica t ion.  We  call  'F'  the  ope r  a  tor  ol  the  application  and  'E' 
the  oper  and  ol  the  application. 


is 


(3)   IL 

'(E)'. 


is  an  expression  ol  the  lambda  calculus,  then   so 


(4)  1l  'x'  is  a  variable,  then  it  is  an  expression  ol  the 
lambda  caicuius. 

(5^  The  only  lambda  expressions  ate  tnose  described   in   (1) 
to  (4)  . 

To  permit  mote  meaningtui  examples,  we  will  sometimes  allow 
additional  types  ol  expressions  within  our  lambda  expressions, 
such  as  conventional  arithmetic  expressions  (e.g.  '3+x'). 

The  way  in  which  we  have  described  the  syntax  of  the  lambda 
calculus  will  form  a  model  for  all  later  syntax  descriptions.  '*re 
have  enumerated  a  set  of  Primitives  (the  basic  symbols  and  vari- 
ables) and  have  described  a  set  of  constructors  or  formation 
rules,  which  will  yield  ail  the  legal  expressions  of  the  language 
when  apoiied  recursively  to  the  Primitives. 

EXERCISES: 

which  of  the  following  are  legal  lambda  calculus  expres- 
sions? 


1.  x 

2.  f(x) 

3.  >x{f(x)> 


-  14  - 


4.  (g)y 

5.  f (a) (b) 

6.  *x{£(x)}  (a) 

7.  AxU(x)  }  (  /x{x}  ) 
3.  f  g 

9.  lg(a)} 

10.  f{x} 

11.  f(>x) 

1.2.7   semantics  o t  the  lambda  calculus . 

In  a  previous  section  we  informally  discussed  evaluation  oi 
expressions  oi  the  lambda  caxculus  by  the  copy  rule.  In  this 
section  this  evaluation  is  denned  mote  exactly  through  two 
t  eduction  rules: 

1  ( r  enaming)  :  one  expression  may  be  reduced  to  another  by 
changing  a  bound  variable  throughout  its  scope  to  any  other  vari- 
able that  does  not  occur  within  that  scope. 

2  (substitution)  :  a  subexpression  oi  the  norm  '/x{E}  (A)  '  may 
be  reduced  by  replacing  it  by  a  copy  or  E  in  which  all  tree 
occurrences  oi  x  are  replaced  by  A,  provided  this  does  not  result 
in  any  tree  variables  or.  A  becoming  bound. 

We  can  restate  the  renaming  rule  as  follows:  An  expression 
'/x{E}*  may  be  reduced  by  renaming  to  an  expression  'Xy{F}'f 
where  F  is  obtained  rtom  S  by  replacing  all  tree  occurrences  or  x 
in  E  by  y.  This  is  only  allowed  it  y  does  not  occur  in  E.  For 
example,  suppose  we  wish  to  rename  x  to  u  in  '>x{ x~+2x+i 1  '  .  We 
do  this  by  changing  to  u  all  rree  occurrences  or  x  in  'x  +2x+I ' . 
This  yields  '>u{u2-2u+i} '.   This  reduction  is  symbolized: 


Ax{x2+2x+l}   =>   /u{u2+2u+i} 

Some  other  reductions  permitted  by  the  renaming  rule  are: 

/x{x}      =>     >a{a}      =>     >g{g}      =>     /r{r} 
/x{>y{x(y)}}       =>      M(>y{r(y)}}       =>      M  (>a  {  r  (a)  }  } 
/x{x+l}       =>      /u{u+x} 
/x{>y{x  +  y}}       =>      >aUy{a  +  y}}       =>      >a{>b{a  +  b}} 

Lets  consider  an  illegal  aoolication  of  the  renaminq  rule  in 
order  to  better  understand  its  restriction.  Suopose  we  wish  to 
aoolv    the    renamino    rule    to 
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f   =  >x{  e*x  }   =   >x{  (2.71828..  .)x  } 

bv  changing  x  to  e.  This  is  not  allowed  since  e  occurs  in 
'e-x'.  We  can  see  that  if  we  did  the  substitution  anywav  we 
would  change  the  meaning  of  the  expression: 

f«   =  >e(  e-e  }   =  >e{  e2  I 

Mote  that  f(l)  =  2.71828...  while  f'(l)  =  1;  f  and  f  are  not  the 
same  function.  Renaming  x  to  y,  however,  would  not  change  the 
meaning: 


f ' '  =  Xy{  e-y  }; 


fl)   =   2.7182*... 


The  renaming  rule  is  generally  needed  only  to  avoid  variable  col- 


lisions . 
EXERCISES: 


Apply  the  renaming  rule  as   indicated,   or   state   that   its 
application  would  be  illegal: 

1.  Ax(*l;   change  x  =>  y. 

2.  /x{>,y{x+y}};   change  y  =>  x. 

3.  >x{t  fx)  1;   change  f  =>  g. 

4.  >d{d+e};   change  d  =>  e. 

5.  Ax{>y {x  (y ) }  }  ;   change  x  =>  f. 

Next  we  will  consider  the  substitution  rule.  The  expression 
'>x{x  +  l }  (3)  '  fits  the  form  required  by  the  substitution  rule:  it 
is  an  application  whose  ooerator  is  an  abstraction.  Hence,  we 
can  reduce  it  by  replacing  all  free  occurrences  of  'x'  in  'x+1' 
by  '3*.   The  result  is  '3+1'.   Now  consider 

>x{  >yfx(y)l  }  (f) 

This  is  an  application  whose  operator  is  the  abstraction 

Axf  Ay{x(y)}  } 


We  can  apply  the  substitution  rule  by  replacing  by  'f'   all 
occurrences  of  'x'  in  '>y{x(y)}'.   This  produces: 

Xy{f  (y) } 


free 
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To  better  understand  the  restriction  on  the  substitution 
rule,  first  consider  this  legal  substitution:  Suppose,  as  is 
usual,  that  e  =  2 .718  28 ...  .  Let  £  =  Ax  {>y{x+y } }  .  Then  we  can 
reduce  f(2e)(l)  as  follows: 

f(2e)(l)   =>  >x0\y{x+y}}(2e)  (1) 

=>  Xy{    2e+y  } (1) 

=  >   2e+l   =>   5.43. ..  +  1   =>   5.43... 

Now  lets  look  at  a  slightly  different  examole: 

f*(2e)(l)   where   f  =  >d{>e{d+eH 

We  see  that  f'  is  the  same  function  as  f;  we  have  just  renamed   x 
and  y  to  d  and  e.   when  we  reolace  f'  by  its  value  we  qet 

Ad{>e{d+ell (2e) (1) 

which  is  an  application  whose  operator  is  the  abstraction: 

>df>efd+e}} 


all    tree 

occurrences  of  'e'  in  'Ae{d+e}'  by  '2e'.  ^ut,  this  is  only 
allowed  if  it  does  not  cause  a  free  variable  of  '2e'  to  become 
bound.  In  this  case  a  collision  does  occur,  since  'e'  is  free  in 
'2e'  but  not  in  'Ae{d+e}'.  To  see  the  reason  for  this  restric- 
tion we  will  go  ahead  and  perform  the  substitution.  The  result 
will  be  'Xe(2e+e}'.  This  has  changed  the  meaning  of  the  expres- 
sion; a  fact  we  can  see  by  evaluating: 

/e{2e+e}  (1)   =>   2*1+1   =>   3 

Hence,   f ' (2e) (1)   =>   3 

although  we  know  the  answer  should  be  5.43....  How  do  we  avoid 
this  situation?  Since  bound  variables  are  arbitrary,  we  simplv 
rename  the  offendina  bound  variable.  For  instance,  we  can  rename 
'e'  to  'c' : 

>d{>efd+e}}  (2e)  (1)   =>  Xd  (Ac  {d+c  } }  (2e)  ( 1) 

which  lets  us  proceed  with  the  reduction: 

/d{  >c{d+c}  }(2e)(l)   =>  >c{2e+c}(l) 
=>   2e+l   =>   5.43. ..+1   =>   6.43... 

In  fact,  this  is  the  major  use  of  the  renaming  rule. 
EXERCISES: 
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Determine  if  the  substitution  rule  is  applicable  to  each  of 
these  expressions.  Tf  so,  reduce  the  expression  by  the  substitu- 
tion rule,  first  appiyina  the  renaming  rule,  if  necessary. 

1.  >x{x(y)Wt) 

2.  >x{  >vfx  (y)  }  }  (y) 
3  .   f  (  3 ) 

4.  ,\xf  >yfx(y)  1  }  (  >z{y  (z)  }  ) 

5.  Ay!yyH3) 

5.   >t  {  f  (3)+f  (4)  }  (g) 

1.2.8   reduced  form. 

If  and  when  an  expression  is  reduced  to  the  extent  that  the 
substitution  rule  can  no  longer  be  applied  to  it,  it  is  said  to 
be  in  reduced  form.  Intuitively,  an  expression  is  in  reduced 
form  when  it  is  an  answer  (i.e.  it  is  done  computing).  The  fol- 
lowing table  shows  examples  of  both  unreduced  and  reduced  expres- 
sions : 


Not  deduced 

Reduced 

>x{xl  fy) 

Ay{f  (y)} (a) 

Ax*  Ay{x(v)}  }  (f) 

Ax{x} (  >xfx}  ) 

>x{x(y)  }  (  >x{x(x)  }  ) 

y 

f  (a) 

Ay(f (y)} 

>x{x} 

y(y) 

In  each  case  above,  the  expression  on  the  right  is  the  reduction 
of  the  expression  on  the  left.  Not  all  expressions  have  a 
reduced  form.   Consider  the  expression  Y(Y)  ,  where  Y  =  Ax{x  (x )  }  : 

Y(Y)   =>   >x{x(x)}(Y)   =>   Y(Y)   =>   ... 

This  is  the  lambda  calculus  equivalent  of  an  infinite  loop. 

EXERCISES: 

Decide  if  each  of  the  following  expressions   is   in   reduced 
form.   If  not,  then  reduce  it  to  reduced  form. 

i.     Aft   f  (3)+f  (4)    }  (  Ay{yyJ   ) 

2.       f  (  Ax{x+x}    ) 
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3.  >x{x<o) (  >x{x+l}  ) 

4.  >x(x<0}  (  ,\x{x  +  l}  (2)  ) 

1.2.9   multiple  parameters  and  other  abbreviations . 

The  lambda  expressions  we  have  defined  have  only  one  bound 
variable.  We  can  get  the  effect  of  two  bound  variables  by  nest- 
ing the  lambda  expressions,  for  instance: 

>x{>y{x+y}} (3) (1) 
=  >  >yn+yHi) 
=>   3+1 
=  >   4 

Recause  such  nested  lambda  expressions  are  so  common,  we  allow 
the  following  abbreviations  (using  ' => '  also  as  a  sign  of  abbre- 
viation) : 

Axy{x+y}   =>  Ax{>y{x+vU 
F(3,l)   =>   F(3)  (1) 

These  abbreviations  are  the  usual  method  of  handling  multi- 
argument  functions  in  the  lambda  calculus.  Of  course,  it  is  not 
normally  necessary  to  think  of  these  as  abbreviations;  we  just  do 
the  multinle  parameter  substitutions  directly,  e.g., 

if  f  =  >xy{x+yl 
then  f  (3,1) 

=  >  >xy{x+y}  (3,1) 
=>   3+i   =>   4 

In  exactly  the  same  way  we  will  allow  substitutions  involving  any 
number  of  parameters,  including  none. 

>abc{ax2+bx+c}  (9  ,6  ,1)   =>   9x2  +  ^x  +  l 

>{m+l}  ()   =>   m+1 

As  we  have  seen  in  some  of  the  previous  examples,  lambda  expres- 
sions can  get  quite  large.  In  order  to  be  able  to  program  signi- 
ficant functions  in  the  lambda  calculus  we  will  need  a  way  of 
attaching  names  to  lambda  expressions.  Therfore  we  will  allow 
rewriting  rules  of  the  form: 

plusp   =>  >xfx>0} 
minusp   =>  >x{x<0} 
succ   =>  >x{x+l} 
square   =>  Xx{x*x} 
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Then  we  can  write,  for  instance, 


minusp (succ  (2) ) 

=  >  >xf x<0t  (succ  (2) ) 

succ  (2) <0 

>x{x+l} (2) <0 

2+KO 

3<0 


=  > 
=  > 
=  > 
=  > 


false 


1.2.10  the  Church^Rosser  property . 

In  the  above  reduction  we  reduced  the  outermost:   aodication 

first.  We  need  not  have  done  this,  for  instance, 

minusp (succ  (2) ) 

=  >   minuspOx{x  +  l}  (2)  ) 

=>   minusp(2+l) 

=>   minusp (3) 

=>  >x{x<0}(3) 

=  >   3<0 

=>   false 
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STANDARD  REDUCTION  ORDER: 
(by  substitution)   only  if 
in  reduced  form. 


An  application  is  reduced 
its  arouments  are  alreadv 


EXERCISE:  Reduce  to  reduced  form: 

Xt  {succ  (f  (2)+f  (3)  )  }  Ox  {square  (x)+2}) 


EXERCISE:  Suopose  the  following  definitions  are  given 
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Zero   =>  >fc{cl 
One   =>  >fc{f(c)> 
Two   =>  Xfc{f(f(c))} 
Three   =>  >fc{f  (f  (f  (c) ) ) } 

SUPl       =>       >MN{>fc{M(f  ,M(£,c)  )  M 


then,  reduce  to  reduced  form  ' sum (Two , One) ' .  what  is  this  equal 
to?  If  you  wonder  about  the  motivation  for  these  definitions, 
then  try  reducing  'Three  (succ , 0 )  '  and  ' Two (succ , 3 )  '  . 
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Chapter  3 


I  . 3   The  Extended  Lambda  Calculus. 

1.3-1   Conditionals . 

The  lambda-calculus,  as  we  have  been  using  it  so  far,  is  not 
very  useful;  it  is  only  possible  to  define  functions  that  evalu- 
ate strictly  in  order:  there  is  no  decision  making  ability. 
Therefore  we  would  like  to  define  a  function  'if  such  that 
if(c,t,f)  =>  t  if  c  is  true  and  if(c,t,f)  =>  f  if  c  is  false. 
Hence,  'true'  selects  * t '  from  (t,f)  and  'false'  selects  'f  from 
(t,f).  One  way  to  do  this  is  to  define  'true'  and  'false'  so 
that  true(t.f)  =>  t  and  false(t,f)  =>  f.   Thus: 

true   =>  >tf|t 
false   =>  Atfjf 

Then  we  want  if(c,t,f)  =>  c(t,f),  where   c   reduces   to   true   or 
false,  so 

if   =>  >btf|b(t,f)| 

To  see  how  this  works,  suppose  'x=y'  returns  'true'  if  x  equals  j 
and  'false'  otherwise.   Then 

if(  2=0,  25,  37) 

=>   if(  false,  25,  37) 

=  >  Abtf{b(t,f)l  (  false,  25,  37) 

=>   false(  25,  37) 

=>  >tf{f}(  25,  37) 

=  >   37 

[Text  we  will  program  the  logical  connectives:    'and',   'or'   and 
'not'.   Not  is  the  simplest  since  it  just  negates  a  truth  value: 

not (true)    =>   false 
not(false)   =>    true 

That  is,  if  x  is  true  then  not(x)  is  false,  otherwise   not(x)   is 
true.   This  can  be  directly  translated  to  the  lambda  calculus: 

not   =>  Ax[  if(  x,  false,  true  )  } 

The  'and'  function  is  defined  so  that  and(x.y)  is   true   only   if 
both  x  and  y  are  true.   This  is  summarized  in  the  following  truth 
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table: 


AND 

true 

false 

true 

true 

false 

false 

false 

false 

We  can  see  that  if  x  is  true  then  and(x,y)  has  the  same  value  as 
7,  and  that  if  x  is  false  then  and(x,y)  is  false  regardless  of 
the  value  of  y.  We  can  translate  this  directly  into  the  lambda 
calculus : 

and   =>  \xy{    if(  x,  y,  false  )  } 

EXERCISE:  Define  'or'  so  that  or(x,y)  is  true  if  and  only  if  x  or 
y  or  both  are  true.   That  is,  'or'  must  satisfy  the  truth  table: 


OR 

true 

false 

true 

true 

true 

false 

true 

..  .... .... 

false 

Show  that  your  definition  works  by  reducing  ' or (false, true) ' . 

1.3-2   Recursive  Definitions . 

Now  that  we  have  a  conditional,  we    can   define   some   more 
useful  functions.   The  factorial  function  is  defined  so  that 


4! 
3! 
0! 


=   4*3*2*1   =   24 
=   3"2'1   =   6 

=   1 


or  in  general, 


n! 


n(n-1 )(n-2)...(2)(l 


The  factorial  can  also  be  defined  recursively  as  foil 


ows  : 


1  , 


■f   n- 


n=0 


n(n-1 ) ! ,   if  n>0 

Using  the  conditional  it  is  now  easy  to  define  a   function   ' f ac ' 
such  that  fac(n)  =  n! . 

fac   =>  Xn{    if(  n=0,  1,  n  ■  fac(n-1 )  )  I 

Consider  the  computation  of  fac(2): 
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fac(2) 

=>  >n{  if(  n=0,    1,  n*fac(n-l))  }  (2) 

=  >  iff  2=0,  1 ,  2*fac(2-1 )) 

=  >  if (  false,  1  ,  2*fac0  )) 

=>  2*fac(l) 

=  >  2  *  >n{  iff  n=0,  1,  n*fac(n-l))  I  (1) 

=  >  2  *  iff  1=0,  1  ,  1*fac(l-1 )  ) 

=>  2  *  1  *  fac(0) 

=>  2*1  *  \n\    if(  n=0,  1,  n*fac(n-l))  |  (0) 

=>  2  *  1  *  if (  0=0,  1,  0*fac(0-l)) 

=>  2  *  1  *  if (  true,  1,  0*fac(-O) 

=>  2*1*1 

=  >  2*1 

=  >  2 


To  keep  the  above  reduction  readable,  most  of  the  reductions 
associated  with  'if  have  not  been  shown.  Notice  that  in  the 
fourth  to  the  last  line  (the  last  line  with  an  *  if  in  it)  if  we 
had  decided  to  reduce  the  argument  formula  0*fac(-l)  we  would 
have  started  a  never-ending  recursion.   That  is, 

:(0-D) 
0*fac(-1 )) 

0  *  An |  if(  n=0,  1 ,  n*fac(n-1 )) j (-1 )) 
0  *  iff  -1=0,  1 , 
n=0,  1 ,  n*fac(n-1 ))  } (-2)  ) ) 
0  *  iff  false,  1 , 
-1  *  if(  -2=0,  1,  -2*fac(-2-l)  ))) 
=  > 

This  process  may  never  terminate!  What  the  Church-Rosser  pro- 
perty really  says  is  that  two  different  reductions  of  a  formula 
give  the  same  result  provided  they  both  terminate .  For  this  rea- 
son we  avoid  evaluating  any  arguments  of  'if  that  we  don't  have 
to. 

Since  'if  is  such  a  common  function,  we  will  introduce  a 
special  notation  for  it.  This  is  just  an  abbreviation,  it  really 
adds  nothing  to  the  lambda  calculus.  Such  abbreviations  are 
often  called  "syntactic  sugar"  (because  a  little  "syntactic 
sugar"  helps  one  to  swallow  the  lambda  calculus).  For  simple 
|' if s,  such  as  if(b,t,e)  we  will  write  [b->t|e],  which  is  read: 
"if  b  then  t  else  e."  For  nested  'if s,  such  as  if(b,  t,  if(c,  u, 


2  * 

1 

+ 

if( 

0=0,  1 ,  0*fa 

=  > 

2 

* 

1  * 

if (  true ,  1  , 

=  > 

2 

-* 

1  * 

if (  true ,  1  , 

=  > 

2 

* 

1  * 

iff  true,  1  , 
-1  *  >n{  if( 

=  > 

2 

* 

1  * 

if (  true,  1  , 

ie ) )  we  will  write 


[  b  ->  t  I  c  ->  u  t  e  ] 


and  so  forth.   This  can  be  read  "if  b  then  t  else   if   c   then  u 
else   e".    Using  this   notation   the   factorial  function  can  be 
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written 

fac 
1.3-3   Primitives 


=>  An |  [n=0  ->  1  |  n'fac(n-l)  ] 


We  have  seen  that  it  is  possible  to  define  in  the  lambda 
calculus  Boolean  values  (true  and  false),  logical  connectives, 
'if  expressions,  arithmetic  (sum),  and  even  numbers  themselves. 
This  should  lend  some  credibility  to  the  statement  made  earlier 
that  anything  that  can  be  done  on  a  computer  can  be  done  in  the 
lambda  calculus.  For  our  purposes,  there  is  not  much  point  in 
carrying  this  exercise  any  further.  In  the  future,  any 
application-oriented  functions  that  we  might  need  (such  as  arith- 
metic) will  be  introduced  as  extensions  to  the  lambda  calculus. 
For  instance,  the  arithmetic  operations  might  be  introduced  by  a 
set  of  rules  like: 

sumO  ,1  )      =>      2 
sum(l ,2)      =>      3 


or    in   general 

sum(m,n)      =>      m+n 

This  way  we  have  an  application  independent  language  framework 
formed  by  the  lambda  abstraction  and  function  application  syntax, 
and  a  flexible  set  of  application  dependent  primitive  operations 
which  we  can  define  as  the  need  occurs.  Notice  that  again  we  are 
breaking  the  language  down  into  primitives  and  constructors .  In 
the  next  section  we  will  build  a  list  processing  language  by  com- 
bining the  constructors  of  the  lambda  calculus  with  a  set  of 
powerful  list  processing  primitives.  We  will  find  that  many 
apparantly  different  programming  languages  are  really  just 
sugared  versions  of  the  lambda  calculus  with  some  application- 
oriented  primitives  added.  The  following  chart  shows  some  primi- 
tives that  might  be  included  in  languages  intended  for  numerical, 
list  processing,  string  processing  and  data  processing  applica- 
tions . 
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language 

constructors 

primitives 

application 
1   independent 

application 
dependent 

numerical 

Ax{il},  fUJ 

integers,  reals, 
+,  -,  x,  /,  ... 

list  processing 

>,x{E!  ,  f(a) 

lists,  atoms, 

first,  rest,  cons,  ... 

string  processing 

Ax|EI,  f(a) 

strings,  characters, 
substr,  concat,  match,  ... 

data  processing 

Ax|E|,  f(a)   ! 

files,  records, 

move,  read,  write,  ... 

1 .3  -4   Data  Types. 

When  we  extend  the  lambda  calculus  with  new  primitives  we 
will  always  do  it  by  defining  a  set  of  data  values  and  a  set  of 
primitive  operations  on  those  values.  Any  operations  we  wish  to 
perform  on  the  data  values  must  be  constructed  from  the  primitive 
operations.  The  term  data  type  is  used  to  refer  to  a  set  of  data 
values  together  with  a  set  of  primitive  operations  on  those 
values.  For  instance,  the  data  type  integer  is  the  set  of 
integer  data  values: 

...   _3   _p   -1   0   1   2   3   ... 
together  with  the  primitive  operations  on  those  values,  e.g., 

+,  -,  x,  /,  =,  £,    < ,  >,  < , 


Any  other  operation,  e.g.  squaring,  must  be  constructed  from 
given  values  and  primitive  operations: 


;he 


square   =  \n 


nxn 


Similarly,  the  Boolean  data   type   is   composed   of   the   Boolean 
values : 

true,  false 

together  with  the  primitive  operations  on  these  values: 

not,  and,  or,  if,  =,  4- 

1.3-5   The  List  Data  Type. 

In  this  section  we  will  define  the  list  data  type.  The  data 
values  are  called  lists  and  are  written  as  sequences  of  values 
surrounded  by  angle  brackets.   For  instance, 
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<5  3  16> 

is  a  list  containing  the  integers  five,  eight  and  sixteen,  in 
that  order.  Lists  can  have  any  number  of  elements,  including 
one : 

<32> 

This  is  the  list  containing  only  the  integer  32.  Lists  can  also 
be  empty,  i.e.,  have  no  elements: 

<> 

This  is  called  the  null  list .  Lists  can  contain  any  data  values, 
for  instance, 

<5  'cat'  false  1 .6> 

is  a  list  whose  first  element  is  the  integer  five,  whose  second 
element  is  the  string  'cat',  whose  third  element  is  the  Boolean 
value  false,  and  whose  fourth  and  last  element  is  the  real  number 
1  .6.   Lists  can  also  contain  other  lists,  for  instance, 

<5  <9  32>  8  16> 

is  a  list  whose  first  element  is  the  integer  five,  whose  second 
element  is  the  list  <9  32>,  whose  third  and  fourth  elements  are  3 
and  16.   Lists  can  be  nested  in  this  way  to  any  depth. 

We  will  define  three  important  primitive  operations  on 
lists.  The  function  'first'  returns  the  first  element  of  a  list, 
e.g.  . 

first(  <5  8  16>  )   =>   5 

first(  <<1  2>  <3  4>>  )   =>   <1  2> 

In  the  second  example  notice  that  the  first  element  of  <<1  2>  <3 
4>>  is  the  list  <1  2>.  It  makes  no  sense  to  apply  'first'  to  the 
null  list  or  to  an  atom,  which  is  what  we  call  things  that  are 
not  lists: 

firstf  <>  )   is  meaningless 
first(  18  )   is  meaningless 

Null  lists  and  atoms  don't  have  a  first  element. 

A  complementary  operation  to  'first'  is  'rest',  which 
returns  all  of  a  list  except  the  first  element,  e.g., 
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rest(  <5  3  15>  )   =>  <S  16> 
rest(  <<1  2>  <3  4>>  )   =>   <<3  4>> 
rest(  <3>  )   =>   <> 

It  makes  no  sense  to  apply  'rest'  to  null  lists  or  atoms: 

rest(  <>  )   is  meaningless 
rest(  13  )   is  meaningless 

The  'first'  and  'rest'  operations  take  lists  apart;  we  need 
another  operation  to  put  them  together.  This  is  'cons'  (short 
for  "construct"),  which  makes  its  first  argument  the  new  first 
element  of  the  list  which  is  its  second  argument.   For  instance, 

cons(  5,  <3  16>  )   =>   <5  3  16> 

cons(  <1  2>,  <<3  4>>  )   =>   <<1  2><3  4» 

cons(  <5>,  <3  16>  )   =>   <<5>  3  16> 

cons(  5,  <>  )   =>   <5> 

Notice  that  the  first  argument  to  'cons'  does  not  have  to  he  an 
atom,  although  its  second  argument  does  have  to  be  a  list: 

cons(  5,8)   is  meaningless 

The  meaning  of  'first',  'rest'  and  'cons'  is  summarized  in  the 
following  formulas.   In  these,  'x'  represents  any  data  value. 

first(  <x  . . .>  )   =>   x 
rest(  <x  . . .>  )    =>   < . . .> 
cons(  x,  <  .  .  .  >  )   =>   <x  . . . > 

These  operations  can  be  combined,  for  instance, 

first(  rest(  <5  8  16>  )  ) 
=>   first(  <3  16>  ) 
=  >   3 

Hence,  f irst ( rest (L) )  is  the  second  element  of  L. 

The  'cons'  operation  is  the  inverse  of  'first'   and   'rest'. 
For  example,  since 

first (  <5  3  16>  )   =>   5,   and 
rest(  <5  3  16>  )   =>   <8  16>,   and 
consj  5,  <3  16>  )   =>   <5  3  16> 

we  3ee  that 
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cons(  first (<5  S  16>),  rest(<5  8  16>)  ) 
=>   cons(  o  ,    <3  1 5>  ) 
=>   <5  S  16> 

Thus,  the  following  identities  hold  (where  L  is  a  list  and  x  is 
any  value ) : 

f irst ( cons(x,L) )  =  x 

rest ( cons (x ,L) )  =  I 

cons(f irst (L) , rest(L) )  =  L,  if  I  is  non-null 

Another  primitive  that  will  he  useful  to  us  is  the  equality  rela- 
tion.  For  instance, 

5=5   =>    true 
5=6   =>   false 

The  equality  relation  is  only  defined  for  atoms  (e.g.,  numbers, 
strings  and  Boolean  values);  its  use  on  lists  is  meaningless: 

5=<6>   is  meaningless 

The  meaning  of  the  equality  relation  is  summarized  "by  the  follow- 
ing formulas,  in  which  'a'  and  'V  represent  different  atoms: 

a=a   =>    true 
a=b   =>   false 

There  are  only  two  other  functions  that  we  need  to  do  useful  list 
processing.  These  are  'null',  which  asks  if  a  list  is  empty,  and 
'atom',  which  asks  whether  something  is  a  list.   For  instance, 

null(  <>  )   =>   true 

null(  <5  B  16>  )   =>   false 

null(  <<>>  )   =>   false 

The  list  <<>>  is  not  null  because  it  contains  a  single  element, 
namely,  the  null  list,  <>.  The  'null'  function  is  not  defined 
for  atoms: 

null(5)   is  meaningless 

.lull  is  defined  by  the  following  formulas,  in  which  x  is  any 
value : 

null(  <>  )   =>   true 
nullf  <x  . . .>  )   =>   false 

The  'atom'  function  determines  whether  a  value  is  an  atom  or  a 
list,  for  example, 
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atom(  5  )   =>   true 

atom(  <5  3  16>  )   =>   false 

atom(  <5>  )   =>   false 

atojn(  <>  )   =>   false 

The  'atom'  function,  which  is  meaningful  when  applied  to  any 
values,  is  defined  by  the  following  formulas,  in  which  'a' 
represents  any  atom: 

atom(  <...>)   =>  false 
atom(  a  )   =>   true 

The  list  data  type  is  summarized  in  the  following  figure. 


Data  Values: 

atoms:   1,  2,  ....  'cat',  'hat',  ...,  true,  false, 
lists:   <>,  <1  'cat'>,  <'call'  < '  var '  'f>  23>,  -- 

Primitive  Operations: 

first(  <x  . . .>  )   =>  x 

rest(  <x  . . .>  )    =>  <  .  .  .> 

cons(  x,  <  .  .  .  >  )   =>  <x  . . . > 

a=a   =>   true 
a=a'   =>   false 

null(  <>  )   =>   true 
null(  <x  . . .>  )   =>   false 

atom(  a  )   =>   true 
atom(  <...>  )   =>   false 

where  a  is  an  atom  and  x  is  a  list  or  an  atom. 

Figure  1 .   The  List  Data  Type 


1-3-6   Recursive  Problem  Solving. 

In  order  to  better  understand  these  list  processing  opera- 
tions, a  number  of  examples  will  be  presented.  First  we  will 
define  a  function  'sub'  such  that  sub(L,i)  is  the  i-th  element  of 
the  list  L.  For  instance, 

sub(  <5  S  16  25> ,  3  )   =>   16 

sub(  <5  <9  32>  16>,  2  )   =>   <9  32> 

since  <9  32>  is  the  second  element  of  <5  <9  32>  16>.  How  are  we 
going  to  program  this  function?  The  way  to  solve  problems  like 
this  is  to  ask  what  subcases  of  the  problem  are  already  solved. 
In  the   case   of   'sub'  this  is  fairly  easy,  since  by  definition 
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'sub(L,l)'  is  just  the  first  element  of  L.   That  is, 

sub(L,1 )   =  >   first(L) 

The  next  step  in  solving  a  problem  such  as  this  is  to  find  some 
way  to  reduce  the  general  problem  to  the  subcases  that  are 
already  solved.   Notice  that 

sub(  <5  3  16  25>,  3  )   =>   16 
sub(    <S  16  25>,  2  )   =>   16 

Hence , 

sub(L,i)   =>   sub(  rest(L),  i-1  ) 

We  have  reduced  the  original  problem,  sub(L,i),  to  one  that  is 
closer  to  the  solved  problem,  sub(L,l),  since  i-1  is  closer  to  1 
than  i  is.  We  now  have  two  cases,  just  as  in  the  factorial  exam- 
ple : 

sub(L,i)  =>  first(L) ,  if  i=1 

sub(L,i)  =>  sub(  rest(l) ,  i-1  ),   if  i>1 

This  is  easily  translated  to  the  lambda  calculus: 

sub   =>  Ali|  [  i=1  ->  first(L)  I  sub( rest (L) , i-1 )  ]  } 

We  will  try  this  on  sub(  <A  B  C  D>  ,  3): 

sub(<A  3  C  D>,  3) 

=>  >Li|  r  i=l  ->  first(L)  |  sub(rest(L) , i-1 )  ]  }(<A  B  C  D> ,  3) 

=  >  r  3=1  _>  first(<A  3  C  D>)  |  sub(rest(<A  3  C  D>),3-1)  ] 

=  >  sub(<3  C  D>  ,  2) 

=>  [  2=1  ->  first(<B  C  D>^  |  sub^rest(<3  C  D>),2-1)  ] 

=>  sub(<C  D>,  1 ) 

=>  r  1=1  ->  first(<C  D>)  I  sub(rest(<C  D>),  1-1)  ] 

=>  first(<C  D>) 

=  >  C 

The  'sub'  function  is  so  useful  that  we  will  adopt  a  special 
"array  subscripting"  notation  for  it: 

A[i]   =>   sub(A,i) 

Thus,  A[1]  and  first(A)  are  the  same. 

Next   we   will   define   a   function    'append'    such    that 
append (L,M)  concatenates  the  lists  L  and  M.   That  is, 

append(<1    2>,    <3   4   5>)    =>    <1    2   3   4    5> 
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Note  that  this  is  different  from  oons(<1  2>,<3  4  5>)  which  would 
give  us  <<1  2>  3  4  5>-  We  will  use  the  same  problem  solving 
technique  that  we  used  with  'sub'  by  asking:  What  cases  of 
'append'  are  immediately  solvable?  Those  in  which  one  of  the 
lists  to  be  appended  is  null,  for  instance, 

append(  <>,  <4  5  6>  )   =>   <4  5  6> 

In  general, 

append(  <>,  L  )   =>   L 
append(  L,  <>  )   =>   L 

Next  we  must  investigate  how  the  general  problem  can  be  reduced 
to  either  of  these  two  cases.  For  instance,  since  we  know 
append(<>,L)  is  L,  we  can  work  on  reducing  the  first  argument  to 
an  empty  list.   Suppose  we  wish  to  simplify 

append(  <2>,  <3  4  5>  ) 

We  know 

apaend(  <>,  <3  4  5>  )      =>   <3  4  5> 
cons(  2,  <3  4  5>  )   =>   <2  3  4  5> 

so  we  can  see  that 

aupend(  <2>,  <3  4  5>  ) 
=>  cons(  2,  <3  4  5>  ) 
=>   cons(  2,  append(  <>,  <3  4  5>  )) 

Now  let's  consider  a  more  complicated  example: 

append(  <1  2>,  <3  4  5>  ) 

We  already  know  how  to  do 

append(  <2>,  <3  4  5>  )   =>   <2  3  4  5> 

so  all  we  have  to  do  is  reduce  the  new  case  to  this: 

aiDpend(  <1  2>,  <3  4  5>  ) 
=>  cons(  1 ,  <2  3  4  5>  ) 
=>   cons(  1,  append(  <2>,  <3  4  5>  )) 

Summarizing,  we  have 

apiDend(  <1  2>,  <3  4  5>  )   =>   cons(  1,  avven&i    <2>,  <3  4  5>  )) 
appendf  <2>,    <3  4  5>  )   =>   cons(  2,  append(  <>,   <3  4  5>  )) 
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It  should  be  apparent  that  the  general  case  is 

append(x,y)   =   cons(  x[l],  append(  rest(x),  y  )) 

Summarizing,  we  have  the  two  cases: 

append (x,; 7)  =>  y,  if  x  is  null 

append(x, y)  =>  cons(x[l],  append ( rest ( x) ,y) )  ,   if  x  is  non-null 

This  can  be  easily  translated  to  the  lambda  calculus: 

append   =>  Axy{  [  null(x)^->  y 

j  cons(  x[l],  append (  rest(x),  y))  ]  } 

We  will  find  that  all  recursive  definitions  fit  this  pattern:  (1) 
a  stopping  condition  that  forms  the  base  of  the  recursion  and  (2) 
a  recursive  invocation  of  the  function  in  which  the  problem  is 
reduced  to  a  simpler  problem.  In  list  processing  the  stopping 
condition  often  takes  the  form  'null(...)T,  just  as  in  numerical 
functions  it  often  takes  the  form  '...=0'.  You  probably  will 
recognize  a  similarity  between  recursive  functions  and  mathemati- 
cal proofs  by  induction.  This  similarity  simplifies  prooving 
that  recursive  functions  are  correct. 

It  should  be  mentioned  that  if  we  had  decided  to  reduce  the 
second  argument  to  the  null  list  rather  than  the  first,  we  would 
have  found  the  going  much  tougher.  The  list  processing  primi- 
tives favor  working  on  the  beginning  of  a  list,  hence  the  first 
argument  of  'append'.  This  sort  of  intuition  comes  from  practice 
with  using  the  primitives. 

Although  it  is  relatively  easy  to  prove  that  'append'  is 
correct,  we  will  convince  ourselves  bv  working  the  reduction  of 
append(<1  2>,<3  4  5>) • 


aT3T)end(<1  2>,<3  4  5>) 

=>      [    null(<1    2>)    ->    <3   4   5> 


=  > 
=  > 


I    cons(    <1    2>[1],    append(    rest(<1    2>),    <3   4    5>))    ] 

cons(l,    aoioend(<2> ,    <3   4   5>)) 

consO  ,  r  null(<2>)  ->  .  .  . 

I  cons(<2>M  ]  ,ai)pend(rest(<2>)  ,<3  4  5>))] 
cons(2,  aoT3end(<>,  <3  4  5>)  )) 
cons(2,  FnulKo)  ->  <3  4  5>  I  •••  ]  )) 
cons(2,  <3  4  5>  )) 


=  >  cons( 1  , 

=>  cons ( 1 , 

=  >  cons( 1  , 

=>  consO  ,  <2  3  4  5>  ) 

=>  <1  2  3  4  5> 

As  final  example,  we  will  define  the  function  'equal'  which 
returns  'true'  if  its  two  arguments  are  equal  atoms  or  lists 
(i.e.  have  the  same  structure).   (Recall  that  '='  only  works   on 
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atoms,  hence  it  cannot  be  used  to  compare  lists.)  That  is 


equal(  <5  <B  16>  25>,  <5  <3  16>  25>  )   => 
equal(  <5  <S  16>  25>,  <5  <3>  16  25>  )   => 


true 
false 


As  in  the  previous  examples,  the  stopping  point  of  our  recursion 
will  be  those  cases  that  we  can  already  solve.  Then,  we  will 
attempt  to  reduce  the  general  case  to  these  simpler  cases.  A 
good  place  to  begin  in  any  list  processing  problem  is  the  null 
list,  and  this  is  the  case  here;  all  null  lists  are  equal: 

equal (  <>,  <>  )   =>   true 

Another  good  place  to  begin  in  list  processing  is  with  atoms. 
This  is  particularly  true  in  this  case,  since  the  '='  relation 
can  be  used  to  test  equality  of  atoms.   For  example, 


equal (5 ,5) 

=  > 

5  =  5 

=  > 

true 

equal ( 5,6) 

=  > 

5=6 

=  > 

false 

These  cases  can  be  written  more  generally: 

equal(x,y)  =>  true,   if  x  and  y  are  both  null 
equal(x,y)  =>  false,  if  x  or  y  is  null,  but  not  both 

equal(x,y)  =>  true,  if  x  and  y  are  atoms  and  x=y 
equal(x,y)  =>  false,  if  x  and  y  are  atoms  and  x^y 
equal(x,y)  =>  false,  if  x  or  y  is  an  atom,  but  not  both 

It  remains  to  reduce  the  general  case  to  these  solved  cases. 
Consider  ' equal( x,y ) ' ,  where  x  and  y  are  non-null  lists  (if  they 
aren't  then  the  problem  is  solved).  Now,  if  x  and  y  are  non-null 
lists,  what  are  the  conditions  that  must  be  satisfied  to  make 
them  equal?  Clearly,  they  must  have  the  same  number  of  elements 
and  each  of  their  elements  must  be  'equal'.  Since  both  lists  are 
non-null  we  know  that  they  both  have  a  first  element.  Hence,  we 
can  compare  the  first  elements  with  'equal',  delete  them  from  the 
lists  and  then  compare  the  rest  of  the  lists  with  'equal'.  This 
is  the  simplification: 

equal(x,y)  =>  equal( x[ 1 ] ,y[ 1 ] )  and  equal( rest ( x) , rest (y) ) , 
if  x  and  y  are  non-null  lists. 

Putting  our  results  together  allows  a  direct  translation  to  the 
lambda  calculus: 
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equal   =>  X    xj\ 

[    atom(x)  -> 

[  atotn(y)  ->  x=y  I  false  ] 
atom(y)  ->  false 
null(x)  ->  null(y) 
null(y)  ->  false 

equal(x[ 1 ] ,y[ 1 ] )  ->  equal( rest ( x) , rest (y) ) 
false    ! 


The  'atom'  tests  are  done  first  since  they   work   on   all   values 
(atoms  and  lists)  while  'null'  only  works  on  lists. 

EXERCISE:  Write  out  the  reduction  of  equal(<5  <S  16>  25>,   <5   <8 

1 6>  25>) • 

EXERCI_SE:  Define  the  function  'member'  such  that   member(x,y)   is 

true   if  and   only   if   x   is  an  element  of  the  list  y.   That  is 

member(C,  <A  B  C  D>)  =>  true,  but   member(C,   <A   <B   C>   D>)   => 

false.   To  show  that  your  definition  works,  reduce  member(7,  <3  5 

7  9>)  • 

EXERCISE:  Suppose  y  is  a  list  of  pairs,  i.e.  it  has  the  form 


<<a,  b,>  < 


•  <a„  b„>> 


l^  u-|  /  va2  bp>  -  -  •  -~n  »n. 

Define  the  function  'assoc(x,y)'  to  be  the   first   b^   for   which 
x=a^ .   ?or  instance, 

assoc(  'V,  <<*a'  1>  <*b'  3>  <*C  5>>  )   =>   3 
assoc(  7,  <<1  0>  <7  9>  <2  5>  <7  3>>  )   =>   9 

EXERCISE:  Suppose  x  and  y  are  lists  of  the  same  length  and  a  is  a 
list  of  nairs.   For  instance, 


X  =  <X.j   Xo 


V 


7  =  <71  72  •  • '  7^> 
a  =  <<b^  c-|  Xbp  c2> 


<*n  cn» 


Define  ' pairlis(x,y , a) '  to  be  the  list  resulting  from  adding  the 
pairs  <x^  y^>  to  the  front  of  a,  e.g., 

«X1  71>  •••  <xm  ym>  <b1  C1>  ••■  <bn  cn>> 

EXERCISE:  Write  the  list  processing  primitives  (first,  rest, 
cons,  atom,  null)  using  linked  lists  in  Pascal  or  some  other 
language  you  are  familiar  with. 

I-3-7   Syntactic  Sugar . 

With  the  list  processing  primitives  we  really  have  a  small, 
but   usable,  programming  language.   In  fact,  the  language  we  have 
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is  very  similar  to  the  list  processing  language  LISP,  which  we 
will  be  discussing  later.  To  make  the  programming  language 
aspects  of  the  lambda  calculus  more  obvious  we  will  "sugar"  it 
with  an  Algol-style  syntax.  First,  we  will  replace  'V  with 
' proc '  (for  'procedure'),  we  will  write  the  bound  variables  in 
parentheses  separated  by  commas  (i.e.  ' xy '  becomes  '(x,y)'),  '{' 
and  '}'  become  'begin'  and  'end',  '['  and  become  'if  and 
'end if  ,  '->'  becomes  'then'  and  '|'  becomes  either  'elsif  or 
'else'.  When  we  make  these  substitutions  in  the  'equal'  function 
we  get: 

Equal   =>   p_roc(x,y) 
begin 

if  atom(x)  then 

if  atom(y)  then  x=y  else  false  end  if 

el  si  f  atom(y)  then  false 

elsif   null(x)    then    null(y) 

alSJJL  null(y)    then  false 

elsif    equal(x[l],    y[lj)    then    equal (    rest(x),    rest(y)) 

else  false 

endif 
end 

These  conventions  are  summarized  in  the  following  diagram. 

Axy 

■  !r! 

-> 
! 

] 

We  will  use  the  acronym  'ELC'  to  refer  to  the  extended  lambda 
calculus ,  i.e.  to  the  pure  lambda  calculus  extended  by  the 
integer,  Boolean  and  list  data  types  and  extended  by  the  syntac- 
tic sugar  introduced  in  this  chapter. 

ELC  is  quite   similar   to  the   programming   language   LISP. 

Approximate   equivalences   are  shown  in  the  following  chart  (the 

differences  are  fairly  subtle  and  are  discussed  in  a  later 
chapter) . 


=  > 

proc(x,y) 

=  > 

begin  . . .  end 

=> 

if 

=> 

then 

=> 

else  or  elsif 

=> 

endif 
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LLC 

LIS? 

f(a,b) 

(f  a  b) 

\xj{...\ 

(LAMBDA  (x  v)  .  .  .  ) 

<1  <2  3>  4> 

(QUOTE  (1  (2  3)  4) 

first(x) 

(CAR  x) 

rest ( x) 

(CDR  x) 

cons ( x ,y ) 

(CONS  x  y) 

[  c  ->  ...  i  ...  ] 

(COND  (c  . . .)  (T  . . .)) 

x=y 

(SQ  x  y) 

true 

np 

false 

NIL 

The  LISP  program  corresponding  to  our  'equal'  function  is: 

(equal  (lambda  (x  y) 
(  cond 

( ( atom  x)  (cond 

( (atom  y)  (eq  x  y) ) 

(T  NIL))  ) 
( (atom  y)  NIL) 
( (null  x)  (null  y)) 
( (null  y)  NIL) 

((equal  (car  x)  (car  y))   (equal  (cdr  x)  (cdr  y))  ) 
(T  NIL)  ))) 

You  can  now  see  that  languages  can  have  very  different  appear- 
ances even  though  they  are  the  same  underneath.  We  will  find 
that  most  programming  languages  are  sugared  versions  of  the 
lambda  calculus. 

1.3.3  local  declarations  in  mathematical  prose .  If  a  mathemati- 
cian were  to  write  an  expression  such  as 

/ ax+b_g\  m+n-2 


t ax+ D \ m 

k — X~~  ) 

he  would  probably  factor  out  the  common  subexpression 

ax+b 


and  give  it  a  name,  say  'u' 

(u-a)m+n"2 


u 


rr 


^r 


where 


u  = 


ax+o 


This  has  two  advantages.  First,  it  reduces  the  size  and  complex- 
ity of  each  expression  so  that  they  can  be  more  easily  assimi- 
lated by  the  eye.  Second,  by  using  the  same  variable  'u'  in  both 
places   it   makes   it   more  obvious  that  it  is  the  same  identical 
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expression  in  both  places.   Now,  we  can  accomplish  the  same  thing 
in  the  lambda-calculus.   In  particular, 


reduces  to 


K'-r2}  (*?*) 


/ax+b_a\  m+n-2 


ax+fci — rr 


1.3-9   local  declarations  in   the   lambda   calculus 

notation  will   be   defined  as  a  "syntactic  sugaring"  of  function 

application: 

3  where  v=x   =>  >v{E}(x) 

For  instance,  an  expression  such  as  this  (which  is  taken  from  the 
interpreter  discussed  later) : 

eval(  f[l][2],  append(  f[2],  cons(x,<>)  )) 

could  now  be  written 

eval(  f[l ][2] ,  NewSnv  ) 

where  NewEnv  =  append(  f[2],  cons(x,<>)) 

By  analogy  with  functions  of  several  arguments,  it  is  possible  to 
allow  compound  "where"  declarations: 

E  where  v<=X|  and  v2=x2  a?^  '*' 
=  >  >v1  v2-  •  •  !sTTx1  ,x2,  •  .Tf" 

For  instance,  the  expression  fragment 

elsif  e[l]  =  War1  then  a[e[2  ]  ]  [  e[3  ]  ] 

can  be  more  readably  written 

elsif  e[l]  =  ' var '  then  a[ep][vp] 
where  ep  =  er2] 
and   vp  =  e[3j 


There  is  another  way  in  which  mathematicians  use  variable  names. 
If  a  mathematician  is  going  to  use  an  expression  in  a  number  of 
following  lines  then  he  will  often  give  it  a  name  with  a  phrase 
such  as  "Let  u  be  ax^  . "  This  style  of  definition  is  easily 
defined  in  the  lambda-calculus: 
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let    v=x    in   E      =>     >v{EJ (x) 


or    in   general 


let    v-|  =x.j    and    v-^x?    and 
=  >     Av1v2-^TE}fx1 


[  V9=Xp  and  • • • 
"Slfx^xo,  .  .  .  ) 


m  & 


Whether  'let'  or  'where'  is  used  is  largely  a  matter  of  taste  and 
style.  In  general,  'where'  is  appropriate  when  'S'  is  one  line 
or  less  and  'let'  is  appropriate  when  'E'  is  more  than  one  line. 
As  an  example  of  'let',  the ' expression  fragment 

elsif  eh ]  =  'call'  then 

apply (  eval(  e[2],  a),  evlis(  rest ( rest ( e) ) ,  a)  ) 

can  be  written 

elsif  e[l ]  =  'call'  then 
let  closure  =  eval(e[2],a) 
and  actuals  =  eval(  rest ( rest ( e) )  ,  a)  in 
apply(  closure,  actuals  ) 

The  use  of  names  such  as  'closure'  and  'actuals'  makes  the  pro- 
gram more  readable,  albeit,  more  verbose. 

1-3-10  terminology  It  will  be  recalled  that  in  the  abstraction 
'J\xjsj'  the  scope  of  'x'  was  defined  to  be  'E'.  By  analogy,  the 
scope  of  the  variables  defined  by  a  'let'  or  a  'where'  is  defined 
to  be  the  body  of  the  corresponding  abstraction.  Eor  instance, 
in  the  previous  example,  the  scope  of  'closure'  and  'actuals'  is 
the  following  line.  To  put  it  another  way,  the  scope  of  a  vari- 
able is  the  region  of  an  expression  over  which  it  has  meaning. 
This  is  shown  in  the  following  diagrams: 


-scope  o: 

let  v=x  in  E 


V 


j 


Consider  the  following  'let'  or  'where'  expressions: 

E  where  v^  =x^  and  V2  =  Xn  and  • • • 
let  v^  =x.j  and  v?  =  xp  and  •  •  •  in  E 
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The  'vj_  =  xi'  parts  of  these  are  called  definitions ,  declarations 
or  bindings  (because  they  bind  a  bound  variable  to  its  value ) . 
The  'let'  and  'where'  constructs  themselves  are  called  blocks 
(particularly  in  languages  that  delimit  them  with  begin-end 
pairs).  These  constructs  occur  in  most  languages  although  in  a 
variety  of  forms.   For  instance,  the  Algol-68  block 

begin  i  =  3 ;  j=m+1 ; 

i/j 
end 

means  the  same  as  the  lambda-calculus  block 

let  i  =  3  and  j=m+1 
in  i/j 

In  languages  that  use  begin-end  pairs  to  delimit  blocks,  like 
Algol-68,  the  declarations  ('i=3;  j=m+1 '  in  this  case)  are  col- 
lectively known  as  the  head  of  the  block,  and  the  rest  of  it  is 
known  as  the  body  of  the  block.   Thus, 

.-bindings  (definitions,  declarations) 


/begin  i  =  3;  j=m+1 ;  i/j  end 
f  i 1  i i 

block   block  head   block  body 
A  set  of  Pascal  declarations  such  as 

function  g(y: integer ) :  integer; 

const  i=3; 

function  f ( x: integer) :  integer; 
begin   f  :=  x*i+1   end; 

begin   g  :=  f(y)+1   end; 
begin  . . .  end 

means  the  same  as  the  lambda  expression 

let  g  =  proc(y)  begin 
let  i=3  in 

let  f  =  proc(x)  begin  x*i+1  end  in 
f(y)+1   end 
in  ... 

Of  course,  it  is  necessary  to  specify  types   in   Pascal   declara- 
tions, but  not  in  lambda-calculus  bindings. 

As  a  final  example  of  blocks  in   the   lambda-calculus,   con- 
sider the  lambda  expression 
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>i{  Xf\    *i{f(i)}(2)  }(  >x|x*ij  )  }(3) 
'he  meaning  of  this  expression  can  be  clarified  "by  using  blocks: 


let  i  =  3  in 

let  f  =  proc(x)(  x*i  }  in 
let  i  =  2  in 
f(i) 

Although  there  is  no  exactly  corresponding  Pascal   program,   this 
lambda  expression  can  be  translated  into  Algol-68: 

begin  i  =  3; 

begin  f  =  proc (x: int ) int :  (x*i); 
begin  i  =  2; 

f(i) 

end 
end 
end 

1-3-1 1   compound  declarations   Consider  the  two  expressions 


let  v«  =  e<    in  let  v0  =  eo  in  e 


1~c1 


scone  oi  v 


2_c2 

scope  of  vp 


!3 


let  v^  =  e<    and  vp  =  e?  in  e^ 


scope  of  both  v^  and  Vp 


> 


The  second  of  these,  which  is  called  a  comnpound  declaration ,  is 
much  more  than  merely  a  shorthand  form  of  the  first.  Observe 
that  in  the  first  expression  ep  is  within  the  scope  of  Va  , 
whereas  in  the  second  expression  the  scope  of  both  v.  and  v0  is 
just  e-r  •   ?or  instance,  while 

let  i=3  in  let  x=A[i]  in  E 

has  the  same  effect  as 

let  x=a[3]  in  3 

the  expression 

let  i=3  and  x=a[i]  in  B 

is  illegal  (i.e.  doesn't  make  any  sense),  unless,  of  course,   'i' 
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is  bound  in  some  surrounding  scope.  This  can  be  seen  more 
clearly  by  translating  the  two  expressions  back  to  pure  lambda 
notation.   The  first  becomes: 

bound  occurence  of  ' i ' 


Ai{  Ax{3}(  A[i] 
i i 

scope  of  'x 


(3) 


scope  of  ' i ' 
which  is  correct,  and  the  second  becomes 

Aix{B|(  3,  A[i] 


scone  of 


and 


unbound  occurence  of  '  i  ' 


which  is  not.   The  most  important  use  of  compound  declarations  is 
in  connection  with  recursive  declarations,  discussed  next. 

1.3-12   recursive  declarations   Consider  a  declaration  such  as 

let  fac  =  proc(n){  [n=0  ->  1  !  n*fac(n-l)]  } 

in  B 
j 

scone  of  ' fac ' 


V. 


This  is  illegal,  as  we  can  see  by  putting  it  in  pure  lambda  nota- 
tion: 

Afac{3}(  \n{    Tn=0  ->  1  |  n*fac(n-l)]  j  ) 


scope  of  'fac' 


unbound  occurence  of  'fac' 


The  recursive  occurence  of  'fac'  is  unbound.  This  is  because  the 
value  on  the  right  of  a  binding  is  evaluated  in  the  surrounding 
environment.  This  is  clearly  an  unsatisfactory  situation. 
Although  there  are  ways  of  handling  recursive  definitions  in  a 
purely  applicative  way,  they  involve  complicated  mathematics  and 
so  will  not  be  discussed  here.  Instead,  the  technique  to  be  used 
will  require  some  of  the  imperative  facilities  discussed  in  the 
next  chapter.  Although  the  actual  technique  to  be  used  will  not 
be  described  until  the  next  chapter,  recursive  definitions  will 
be  used  in  this  chapter. 


A  declaration  of  the  form 
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let  rec  v=e  in  B 


scope  of  'v' 

is  called  a  recursive   declaration 
because   the   scoiDe   of  '  v'  includes 


or 


definition 
Therefore 


or 


use  of  'v' 
defined  so 


Similarly,  compound  recursive  declarations 

that  in 


let  rec  v^=e^ 
and  rec  Vp=e2 


and 


m 


"V. 


the  scopes  of 
definition  o^ 


scope  of  v^  ,  V2 


binding) 
can  make 
will   be 


f  V|,  Vp,  •••  include  e^  ,  $2  >     •••  •   This  allows   the 
f  mutually  recursive  functions,  for  instance: 

Sval  =  proc(e,a)|  ...  apply( . . . )  ...  } 
Apply  =  proc(f,x){  ...  eval(...)  ...  } 


let  rec  Eval  =  proc^e,a 
and  rec  Apply  =  proc(f,x) 
in  .  . 
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Chapter  4 

I  .  4   Implementing  The  Lambda  Calculus 

1.4.1  goals  defined . 

You  have  probably  found  reducing  lambda  calculus  expressions 
to  be  a  tedious  and  error-prone  process.  These  characteristics, 
plus  the  fact  that  reduction  is  a  mechanical  procedure,  makes  the 
computer  the  ideal  tool  for  doing  these  reductions.  There  are 
several  reasons  for  this.  When  peoole  work  for  a  long  time  at  a 
mechanical  task,  they  become  tired  and  begin  to  make  mistakes. 
Computers  aren't  like  that:  once  programmed  correctly  they  will 
perform  a  task  without  fatigue.  Another  advantage  of  using  com- 
puters to  do  reductions  is  that  they  can  do  them  so  fast.  The 
mechanical,  symbolic  processes  of  a  calculus  are  exactly  what 
computers  handle  best,  since  a  computer  is  just  a  very  fast  sym- 
bol manipulator. 

Why  are  we  so  concerned  about  reducing  lambda  exoressions, 
anyway?  As  you've  seen  in  the  orevious  chapter,  languages  with 
very  different  appearances  are  often  just  "sugared"  versions  of 
the  lambda  calculus.  You've  also  been  told  (and  you  will  see  it 
in  Part  II)  that  most  common  programming  languages  are,  under- 
neath, just  the  lambda  calculus.  Therefore,  if  you  study  how  to 
implement  the  lambda  calculus,  you  will  be  learning  how  to  imple- 
ment most  of  the  common  programming  languages.  The  advantage  of 
using  the  lambda  calculus,  as  opposed  to  Pascal  or  Ada,  for 
instance,  is  that  the  lambda  calculus  is  so  simple.  The  imple- 
mentation techniques  are  much  easier  to  understand  in  the  clear 
and  uncluttered  context  of  the  lambda  calculus.  Once  understood, 
they  are  easy  to  extend  or  modify  so  that  they  accomodate  the 
complexities  of  "real"  languages. 

1.4.2  mechanical  reduction 

Having  established  that  imolemenat ion  of  the  lambda  calculus 
is  important,  we  can  proceed  to  study  how  we  might  go  about  it. 
The  obvious  aporoach  is  to  write  a  program  that  duplicates  our 
hand  reduction  procedures.  This  is  easier  said  than  done,  how- 
ever . 

Let's  investigate  how  we  might  go  about  automating  the 
reduction  process.  When  we  reduce  a  lambda  expression  using  the 
Standard  Reduction  Order,  we  do  it  by  applying  the  substitution 
rule   over   and   over,  until  we  are  forced  to  stop  by  an  immanent 
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collision  of 
the  offending 
and  continue 
lambda  expres 
collision  of 
is   the   sort 
for  computers 
glance,   whil 
search.   That 
tute   an   act 
variable,  it 
variables   in 
the  expressio 
It   is   then 
contain  the  p 
any   of   thes 
actual  parame 
intricate  and 


variables.   We  then  use  the  renaming  rule 

bound  variable  to  one  that  won't  cause  a 
with  our   substitutions.    Except   on   ver 
sions  it  is  generally  easy  to  see  if  there 
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Another  reason  to  avoid  a  mechanical  implementation  of  the 
reduction  procedure  is  that  it  would  be  slow.  As  you've  probably 
observed  in  your  own  reductions,  this  process  involves  a  lot  of 
recopying  of  the  formulas.  This  is  something  that  most  computers 
don't  do  well.  For  these  reasons  we  will  investigate  an  imple- 
mentation that  involves  neither  textual  substitution  nor  a  com- 
plicated coll ision-of-var iables  test. 

1.4.3   context 

Let's  take  another  look  at  the   way   people   use  variables. 

Suppose   a   mathematician  reads  a  phrase  such  as,  "Let  9  =  2ltft." 

what  happens  when  he  later  reads  a  formula  such  as 
"2sin  6  cos  9"?   Does  he  mentally  transform  this  into 

2sin(2ifft)  cos(2i»ft) 

by  performming  the  substitutions?  Of  course  not.  Having  been 
told  "Let  9  =  2iTft",  he  remembers  this  fact  and  associates  9  with 
2lfft.  we  say  that  he  has  bound  9  to  2lTft.  When  he  reads  the 
formula  "2sin  9  cos  9"  he  interprets  it  contextually ,  i.e.,  in 
the  context  of  the  relevent  meanings  of  2,  sin,  cos  and  9.  It  is 
not  necessary  for  him  to  do  a  textual  substitution. 


You  will  remember  that  the  reason  for  the  collision-of- 
variables  restriction  on  the  substitution  rule  was  to  prevent 
altering  the  meaning  of  an  expression  by  changing  the  context  of 
its  interpretation.  In  this  case  the  context  is  just  a  set  of 
bindings ,  i.e.,  associations  between  variables  and  their  values. 
In  the  next  section  you  will  see  how  to  keep  track  of  the  context 
of  a  formula  in  such  a  way  that  it  can  be  evaluated   without   the 
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use  of  substitution,  renaming  or  collision  tests. 

1.4.4   hand  evaluation 

In  this  section  we  will  study  the   use   of   the   context   or 

environment  of   a   formula  -  i.e.,  the  set  of  bindings  that  give 

that  formula  its  meaning.   These  will  be  represented  by   diagrams 
of  the  form: 


9 

2itf  t 

2s  in 

8    cos    8 

This   expreses   the   fact   that   the   context   of    the    formula 
'2sin  8  cos  8'  is  the  binding  of  8  to  2ftft. 

^s  our  first  examole,  let's  consider  the  evaluation  of  ' x+1 ' 
in  a  context  in  which  x  is  bound  to  2,  i.e., 


«      2 

X+i 

Since  this  is  the  context  of  the  entire  formula,  it  is  also  the 
context  in  which  each  of  its  subformulas  must  be  interpreted. 
Hence,  this  can  be  reduced  to 


x  I  2        x  J  2 

x+1 


Now,  the  interpretation  of  x  in  the  context  x=2  is  just  2,  so   we 
have 


and  the  interpretation  of  1  in  any  context  is  1,  so 

2+1 
or  3.   Similarly,  we  can  evaluate  x*y  in  the  context  y=3 ,  x=2. 


y 

3 

=  > 

v   1  3 

X 

2 

x   J   2 

x  *y 

X 

y 

3 

X 

2| 

y 

=>    2-3    => 


Next,  we'll  take  a  more  complicated  example,   the   evaluation   of 
'Ay { x*y} (x+i) '  in  the  environment  x=2: 


>y{x-y} (x+i) 
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Before  we  can  bind  y  to  x+1  we  have  to  know  the  value  of  x+i  (in 
context,  of  course).  Hence,  we  will  separate  the  two  parts  of 
the  application: 


7T 


/y(x-y} 


( 


x+1 


) 


Notice  that  we  have  kept  the  formula  ,\y{x*y}  in  context  -  other- 
wise it  would  lose  its  meaning.  Continuing  our  evaluation,  we 
previously  saw  that  x+1  in  the  context  x=2  evaluates  to  3,  so  we 
have : 


2 


>y(x*y} 


(3) 


what  is  the  effect  of  >y{x*y}(3)?   It  is  to  add  the   binding   y=3 
to  the  context  of  interpretation: 


y 

3 

X 

2 

x'y 

We  have  previously  seen  that  this  reduces  to  6. 

We  will  expand  on  the  previous  example  a  little.  In  that 
example  we  applied  to  the  argument  3  the  function  ,\y{x'y}  in  the 
context  x=2,  i.e.,  the  funnction  represented  by 


Ay{x*y} 


Next  we  will  consider  the  evaluation  of  f(3)  in  a  context  that 
binds  f  to  the  above  function.  The  result,  of  course,  should  be 
the  same.   We  start  with 


f 

x    I   2|             I 

>y{x-y)  | 

f  (3) 

We  must  evaluate  the  operator  and  operand  seoarately: 


/ 

x  _zj                 I 

X-jix-j}     | 

3 

Constants  are  independent  of  the  context,  so  the  operand's   value 
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is   3.    The  operator  is  a  variable,  f,  which  must  be  interpreted 
in  the  context.   When  when  we  substitute  this  definition  we  get: 


x  |  2 

>y  {  x  *  y  } 


(3 


which  we  have  already  seen  is  6.  Notice  that  we  have  always 
preserved  the  meaning  of  Ayfx'y}  by  bringing  the  context  along 
with  it.  We  are  now  at  the  point  where  we  can  formally  state  our 
evaluation  rules. 

1.4.5   constants 


Since  the  value  of  a  constant  does  not  deoend   on 
text,  we  evaluate  it  by  eliminating  the  context. 


=  > 


its 


con- 


c 

\ 

{ 

for  k  a  constant. 

1.4.6   variables 

Tn  contrast  to  constants,  the  value  of  a  variable  depends 
entirely  on  the  context.  We  find  the  value  of  a  variable  by 
looking  it  up  in  the  list  of  bindings  in  the  contour  (bv  conven- 
tion, we  take  the  first  occurence  of  the  variable  in  that  list). 
The  rule  is: 


=  > 


: 

V 

X 

: 

V 

where  v  is  a  variable. 


If  x  is  not  bound  in  this  context,  then  it 
as  we  know  it  has  no  value) . 


s  free  (  i  .  e 


so 


tar 


1.4.7   abstractions 


An  abstraction  often  will  have  free  variables  that  are 
defined  in  its  context.  If  this  context  is  not  preserved  then 
the  abstraction  will  change  its  meaning.  Therefore,  we  will 
leave  an  abstraction  unevaluated  until  it  is  ready  to  be  applied 
to  some  arguments.   We  show  this  delay  of  evaluation: 
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>x{E} 


=  > 


>x{f:} 


(no  change) 

1.4.3   applications 

Consider  an  application  such  as  'f(x+l)'. 
tion  Order  says  that  in  order  to  determine  its  value  it  is  first 
necessary  to  determine  the  value  of  its  operand,  ' x+1 ' ,  and  its 
operator,  'f'.  Of  course  the  value  of  each  of  these  is  found  by 
interpreting  it  in  the  context  of  the  entire  application: 


Standard   Reduc- 


r 

tie) 

=  > 


c 

f 

( 


Of  course,  there  is  more  to  the  evaluation  of   applications   than 

this.   If  the  application  is  to  make  sense  then  the  evaluation  of 

the  operator  must  result  in  an  abstraction  (with   its   context). 
That  is,  we  will  get  a  result  like: 


>x(H} 


(A) 


Now,  this  means  that  C  is  the  context  of  the  abstraction  >,x{5}. 
The  application  above  is  evaluated  by  adding  the  binding  x=A  to 
the  context  C,  and  then  using  this  as  the  context  in  which  to 
interpret  E.   Summarizing,  the  rule  is: 


G 


Xx{E) 


(A) 


=  > 


x    !  A 

r 

E 

1.4.9   primitive  applications 

We  have  already  seen  several  examples  of  the  evaluation  of 
primitive  applications,  such  as  'x+1'  and  'x'y'.  In  each  of 
these  it  was  first  necessary  to  evaluate  the  operands  of  the 
primitive.   This  leads  to  the  general  rule: 


C 


o (  xl ,  . . . ,  xn 


=  > 


1.4.10   conditionals 


P( 


xl 


xn 


Recall  that  we  specified  a  deviation  from  Standard  Reduction 
Order  for  conditionals.  We  said  that  we  would  first  reduce  the 
condition  and  then,  depending  on  whether  the  result  was  'true'  or 
'false',  reduce  either  the  true  branch  or  the  false  branch.  This 
avoids  errors   in   situations   where   the   other   branch   is   not 
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reducible.   Reducing  the  condition  is  accomplished  by  the  rule: 


ZT 


[  b 


=  > 


r 

-»    t 

f    1 

c    ! 

b 

When  the  condition  has  evaluated  to  'true'  or  'false'  the  follow- 
ing rules  interpret  in  context  the  corresponding  branch. 


c 

f    ] 

[ 

true    —»    t    1 

c 

false    -^    t 

1    f    1 

< 

=  > 


=  > 


c_ 

t 


1.4.11  example  of  hand  evaluation 

As  an  example  of  these  procedures  we  will  evaluate 

let  i=3  in 

let  f  =  proc(x) {  x*i  }  in 
let  i=2  in 
f  (i) 

which  we  saw  in  Chapter  3.  The  crucial  aspect  of  this  example  is 
that  the  context  of  oroc(x) {x'i}  is  i=3.  We  can  see  that  this 
context  is  preserved  in  the  following  figure.  In  this  example  we 
first  eliminate  syntactic  sugar  and  write  the  above  formula: 

Xi{   Xt{   Xi{    f(i)  1(2)  }(>x{x-i}  )  }(3) 

1.4.12  representation  def  ined 

We  will  next  write  an  interpreter  for  ELC  (the  extended 
lambda  calculus)  in  ELC.  Since  we  will  be  using  ELC,  and  the 
only  primitives  we  have  in  ELC  are  for  manipulating  lists,  we 
will  have  to  encode  lambda  expressions  as  lists  so  that  they  can 
be  manipulated.   This  is  the  representation  we  will  use: 


FORM 


EXAMPLE 


REPRESENTATION 


constants 


variables 
abstractions 
applications 
prim,  applies 
conditionals 


string 
<5  8  16> 
x 

Axy{E} 
F(A,B) 
cons (A,B) 
[  c  -»  t 


f  1 


<'const'  2> 
('const'  'string'> 
<'const'  <5  8  16>> 
<*var'  'x'> 
<'lambda'  <'x'  'y' 
<*call'  F  <A  B>> 
< ' pr im '  ' cons '  <A 
<'if  c  t  f> 


>  E> 


B>> 
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J) 


\J 
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Figure  I.   Example  of  Hand  Evaluation 

It  is  necessary  to  append  the  "taq  word"  'const'  to  the  beginning 
of  constants  to  prevent  confusion,  for  instance,  between  the 
lists  representing  variables  and  constant  lists  that  happen  to 
begin  with  the  string  'var'. 


We  will  look  at  several  examples   of   lists   that   represent 
lambda  expressions.   The  expression 
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t  ( 1  ,  2 ) 

is  reoresented  bv  the  list: 

<"call'  <'var'  ,f'>«'const'  i>  <'const'  2>>  > 

The  primitive  application 

cons (y , <>) 

is  represented  by 

<'orim'  'cons'  «'va>"  'y'>  <'const'  <>>  » 

For  a  more  complicated  example,  consider: 

>xy{  cons  (  x,  cons  (  y,  <>  ))  } 

This  is  reDresented  by 

<'lambda'  <'x'  'y'> 

<'prim'  'cons'  «'var'  'x'> 

<'prim'  'cons'  «*var*  v'> 

< 'const'  <>>  >>>  » 

1.4.13   field  accessing  functions 

SuDDose  L  is  a  list  reoresentino  an  abstraction,  e.q., 

<'lambda'  <'x'  'y'>  <'var*  'x'>> 

It  we  wish  to  extract  the  bound  variables  from  L,  we  can  do  this 
by  L [21 : 

L [21   =>   <'x'  'y'> 

Similarly,  the  body  of  the  abstraction  can  be  extracted  by  LT31: 

L  [  31   =>   <'var'  'x'> 

Both  of  these  ooerations  will  be  more  readable  if  we  define  the 
field  access  inq  functions  ''bvs-'  and  "body'1  to  qet  the  bound  vari- 
ables and  body,  respectively,  of  an  abstraction: 

let  bvs  =  oroc(x){  x[21  } 

and  body  =  oroc(x)f  x[31  }   in  ... 

Then  we  can  write 
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bvs(L)   =>   <'x'  'y*> 
body(L)   =>   <'var'  'x'> 

It  will  also  be  useful  to  have  a  function  'is-lambda'  to  tell  us 
if  a  list  represents  an  abstraction: 

let  is-lambda  =  oroc(x){  x[ll  =  'lambda'  }  in  ... 

This  function  determines  if  a  list  reoresents  an  abstraction  by 
checking  if  its  ''tag  word"  is  'lambda*.   For  instance, 

is-lambda (L)   =>   true 

is-lambda(  <'con3t*  2>  )   =>   false 

Of  course,  we  will  want  functions  like  'bodv'  and  'is-lambda'  tor 
each  of  the  lists  which  reoresent  a  tyoe  ot  lambda  expression. 
Rather  than  define  each  separately  like  we  did  above,  we  will  use 
the  abbreviation 

structure  lambda:  (bvs,  body) 

to  mean  that  lists  whose  first  element  is  'lambda'  will  have  two 

more   elements,  selected  by  the  functions  'bvs'  and  'body'.  This 

is  called  a  structure  definition  and  is  equivalent  to  the 
declaration: 

let  is-lambda  =  oroc(x){  x[ll =' lambda '  } 
and  bvs  =  oroc(x) (  x[21  } 
and  body  =  proc(x) (  x[31  } 
in   ... 

The  structure  declarations  tor  the  lists   that  reoresent   lambda 

expressions  are  given  in  the  following  figure.  The  definition  of 

these  tield  accessing  functions  will  make  our  interoreter  much 
more  readable. 


structure 

const:  (constval) 

structure 

var :  (id) 

structure 

lambda:  (bvs,  body) 

structure 

call:  (rator,  rands) 

structure 

prim:  (rator,  rands) 

structure 

it:  (cond,  t-branch ,  f-branch) 

figure  2. 

Lists  Representing  Lambda  Expressions 

1.4.14   association  lists. 


So  that  environments  (contexts)  can  be  manipulated  by  the 
primitives  with  which  we  have  equioped  the  lambda  calculus,  we 
will  define  a  reoresentat ion ,  called  an  association  list   (or   a- 
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list) ,  for  environments.  ^n  association  list  is  just  a  list 
wherein  each  element  ot  the  list  is  a  pair  containinq  the  name  ot 
a  variable  and  its  value.  Por  instance,  an  association  list 
representing  an  environment  in  which  x=2,  v='^onterev'  and  z=<0  1 
2>  is: 

<  <'x'  2>  <'y'  'Monterey'>  <'z'  <0  1  2>>  > 

We  will  define  several  Drimitive  functions  on  association  lists. 
The  function  'assoc'  is  defined  so  that  'assoc(x,a)'  is  the 
result  ot  looking  uo  that  variable  name  x  in  the  association  list 
a  . 


let  rec  assoc  =  proc(x,a)  begin 

if  equal  (  x,  ailHH)  then  a  r  1 1  T2] 
else  assoc(  x,  rest(a))  endif  end. 

por  instance,  if  L  is  the  a-list 

<  <'x'  2>  <'y'  'Monterey'>  <'z'  <r>    1  2>>  > 

then 

assoc(  'y',  L)  =>  'Monterey'. 

The  function  'pairlis'  is  a  little  more  complicated ;  it  is  used 
for  binding  variables  to  values  and  adding  them  to  an  association 
list.  That  is.  if  x  is  a  list  ot  variable  names :  y  is  a  list  of 
values  and  a  is  an  association  list,  then  ' na i r 1  is (x , y , a )  '  is  an 
association  list  in  which  each  element  of  x  is  oaired  with  the 
corresoonding  element  of  y  and  apoended  to  the  front  of  a.  por 
instance , 

pairlis(  <'w'  'cost' >,  <^  25>,  L  ) 

=>   <<'w'  o>  <'cost'  2S>  <'x'  2>  <'y'  'M0nterey'>  <'z"  <0  1  2>>> 

To  see  how  this  can  be  done,  notice  that  if  'a'  is  an  a-list,  and 
<xi  yi>  is  a  pair  representing  a  binding,  then 

cons (  <xi  y i>  ,  a) 

will  add  this  oair  to  'a'.  The  resulting  definition  of  'pairlis1 
is: 

let  rec  pairlis  =  proc(x,y.a)  begin 
if  null  (x)  then  a 
else  cons  (  oair(  x[ll,  y  T 1 ]  ), 

pairlis(  rest(x),  rest(y),  a)  )   en^if  end 
where  pair  =  proc(x,y){  cons (    x,  cons  (  y,  <>  ))  }. 
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1.4.15   closures 

We  have  previously  seen  that  it  is  necessary  to  keep  an 
abstraction's  context  with  that  abstraction  in  order  to  preserve 
its  meaning.   We  have  symbolized  this  with  diagrams  like: 


>y{x+y} 


We  will  now  investigate  in  more  detail  the  nature   of   this   con- 
struct . 


A  formula  is  called  closed  if 
instance , 


t  has  no  free  variables,   for 


>x{  Ay{x+y}  } (3) 

Closed  formulas  are  important  because  their  interpretation  is 
completely  independent  of  context.  A  formula  is  called  open  if 
it  has  one  or  more  free  variables.  Hence,  open  formulas  are 
dependent  on  their  context  for  their  interpretation.  This  for- 
mula is  open: 

>y{x+y} 

An  open  formula  can  be  closed  by  providing  bindings  for  its  free 
variables.  For  instance,  the  above  open  formula  can  be  closed  by 
binding  x  to  3 : 


let  x=3  in  >y{x+y} 


or 


>x  {  >y{x+y}  } (3) 


This  is  called  the  closure  of  the  formula  >y{x+y}.  More  gen- 
erally,  a  closure  is  a  formula  together  with  bindinqs  for  all  of 
its  free  variables.  This  is  just  the  construct  we  have  illus- 
trated by 


x       3 

>y{x+y} 

Our  next  task  will  be  to  determine  how  we  can  implement  closures 
using  lists.  The  key  is  our  diagram;  a  closure  has  two  parts: 
an  abstraction  and  its  context.  These  parts  are  traditionally 
called  the  _i_p  and  e_p,  which  stand  for  instruction  part  and 
environment  part,  respectively. 


We  will  represent  a 


structure 
list  that 


with  two  fields  called  'ip'  and  ' ep 


The 


closure  by 
ip  will  be 


represents  an  abstraction  and  the  ep  will  be  an   a-list 
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representing  a  context.   This  is  summarized  by 

structure  closure:  (in,  ep) 

The  function  for  constructing  closures  is  defined: 

let  closure  =  proc(ip,ep){ 

cons(  'closure',  pair(  ip,  eo  ))  } 

Thus,  we  can  make  a  closure  from  the  abstraction  f  and  the 
environment  e  by  closure  (  f , e) : 

closure(f,e)   =>   <'closure'  f  e> 

We  can  test  if  something  is  a  closure  bv  is-closure(c)  and 
extract  its  Darts  by  ip(c)  and  ep(c).  The  closure  data  type  is 
described  in  the  following  figure. 


ip(  closure(f,e)  )   =   f 
ep(  closure(f,e)  )   =   e 
closure(  ip(c),  ep(c)  )   =   c 
is-ciosure(  closured, e)  )   =   true 

where  is-lambda (f ) 
and    e  is  an  a-list 
and    is-closure (c) 

Figure  3.   The  Closure  Data  Type 


1.4.15   mechanical  evaluation . 

We  will  define  a  function  'eval'  such  that  if  'e'  is  a  list 
representing  a  lambda  expression  and  'a'  is  an  association  list 
representing  an  environment,  then  'eval(e,a)'  is  the  result  of 
evaluating  that  lambda  expression  in  that  environment.  Thus, 
'eval(e,a)'  corresponds  to 


a 

e 


The  structure  of  our  interpreter  will  be  a  large  conditional  so 
that  we  can  handle  lambda  expressions  case  by  case.  In  skeleton 
form  it  is: 
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let  rec  Eval  =  proc(e,a) 


begin 
if 

elsif 
e  1  s  i  f 
elsif 
elsif 
elsif 
end  if 

end 


is-const (e) 
is-var (e) 

is-lambda  (e) 
is-call (e) 
is-or  im (e) 
is-if  (e) 


then 

then 

then 

then 

then 

then 

in 


We  will  consider  each  of  these  cases  in  turn.  In 
them,  it  will  be  helpful  if  you  refer  back  to  the 
defined  in  figure  2. 


d  iscussing 
field  names 


The  simplest  case,  as  we  have  already  seen,  is  constants, 
because  they  do  not  depend  on  the  context  tor  their  interpreta- 
tion. In  this  case  we  just  extract  the  constant  value  from  the 
list  and  return  it: 

if  is-const(e)  then  const-val  (e) 


The  next  simpler  case  is  variables. 
< ' var '   x> 
envi  ronment 


The 


result 


is   just   the   result   of  looking  up  x 
(which  is  the  a-iist  bound  to  'a'): 


of   evaluating 
in  the  current 


elsif  is-var(e)  then  assoc (  id  (e)  ,  a) 

^s  discussed  in  the  previous  sections,  the  rule  for  abstractions 
will  form  a  closure  by  combining  the  abstraction  and  its  environ- 
ment of  definition  (context).   This  is  accomplished  by: 

elsif  is-lambda(e)  then  closure(e,a) 


Wh  e  n 

the 

(ep) 

the 

(ip) 


this  closure  is  applied  to  its  operands  by  a  application, 
'apply'  function  will  extract  the  environment  of  definition 
from  the  closure  and  use  it  as  the  basis  for  constructing 
environment   of   evaluation   for  the  bodv  of  the  abstraction 


Mext  we  will  consider  the  case  of  Primitive  applications. 
If  e  is  a  primitive  application  then  rator(e)  is  its  operator, 
which  is  a  string  such  as  'first'  or  'cons',  and  rands(e)  is  a 
list  of  its  operands.  In  our  hand  evaluation  procedure,  we  first 
interpreted  the  operands  in  context  and  then  performed  the  primi- 
tive  operation.   Here  we  will  use  an  auxilliary  function  'evlis' 


to  evaluate  the  operands  and  an  auxilliary  function 
to  perform  the  operation: 


' apply-pr im ' 
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elsif  is-prim(e)  then  apply-orim(  rator(e),  actuals) 
where  actuals  =  evlis(  rands(e),  a) 

Evlis  is  a  simple  recursive  procedure  that  evaluates  each  element 
of  its  argument  list  and  returns  a  list  of  the  results: 

let  rec  evlis  =  proc(L,a)  begin 
if  null(L)  then  <> 
else  cons  (  eval(  L[ll,  a),  evlis(  rest(L),  a))   endif  end  in 


The  definition  of  ' apply-pr im '  is  simply  a  conditional 
dling  each  of  the  primitive  operations: 


for   han- 


let  apply- prim  =  proc(f,x)  begin 


if 

elsif 

elsif 

elsif 

elsif 

endi  f 


f=' first' 
f=' rest' 
f  =  '  c  o  n  s  ' 
f = ' atom ' 
f='null ' 
end  in  .  . 


then  f i  rst  (x  r 1] ) 
then  rest  (x [1 1 ) 
then  cons(  x  [  i  ]  , 
then  atom  (x  [1] ) 
then  null  (x [11 ) 


x[21) 


Of  course, 
just   add 
pr im '  . 


if  we  want  additional   primitive   operations,   we   can 
clauses  for  handling  them  to  the  definition  of  'aoply- 


The  application  of  non-orimitve  operations  is  a  similar  pro- 
cess. The  operands  must  be  evaluated  using  'evlis',  as  was  done 
for  primitive  applications.  Since  the  operator  is  also  a  for- 
mula, it  also  must  be  evaluated  in  context.   This  evaluation  must 


yield  a  closure.   The 
parameters.   That  is: 


closure   is   then   applied   to   the   actual 


elsif  is-call  (e)  then  apply(  closure,  actuals) 
where  closure  =  eval(  rator(e),  a) 
and    actuals  =  evlis(  rands(e),  a) 

Next,  we  must  consider  what  'apply'  has  to  do  to  complete  the 
function  call.  In  our  hand  evaluation  procedure  we  paired  the 
bound  variables  with  the  corresponding  actual  parameters  and 
added  these  bindings  to  the  context  of  the  abstraction.  This  new 
context  was  used  as  the  environment  for  evaluating  the  body  of 
the  abstraction.   We  will  do  the  same  here. 


If  b  is  the  list  of  bound  variables,  x  is  the  list  of  actual 
parameters  and  c  is  the  context  of  the  abstraction,  then 
pairlis (b , x , c)  is  the  environment  in  which  to  evaluate  the  body 
of  the  abstraction.  The  'apply'  function  that  accomplishes  this 
is : 
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let  rec  apply  =  proc  (  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  pairlis(  bvs(abs),  actuals,  ep(closure; 
eval (  body (abs),  env  )  end 


)  in 


The  only  case  left  to  be  analyzed  is  the  conditional.  In  our 
hand  evaluation  orocedure  we  interpreted  the  condition  in  context 
to  get  a  truth  value.  We  then  used  this  value  to  determine 
whether  to  evaluate  the  true  branch  or  the  false  branch  of  the 
conditional.   This  is  exactly  what  needs  to  be  done  in  'eval': 


elsif  is-if(e)  then 
if  eval  (  cond  (e)  ,  a) 
then  eval(  t-branch  (e) 
else  eval  (  f-branch(e) 


a) 
a) 


end  if 


This  completes  the  definition  of  'eval';  the  complete  interpreter 
is  shown  in  the  following  figure. 


let  rec 

if 

elsif 

elsif 

elsif 
whe 

elsif 
whe 
and 

elsif 
if 
els 

end  if 


Eva 
is* 

is-* 
is- 
is- 

re  a 
is- 

re  c 
a 
i  s 

eval 

e  ev 
end 


1  =  proc(e,a)  begin 

const  (e)   then  const-val (e) 

var(e)     then  assoc(  id(e),  a) 

lambda(e)  then  closure  (  e,  a) 

prim(e)    then  apply-pr im (  rator(e),  actuals! 

ctuals  =  evlis(  rands(e),  a) 

then  apply  (  closure,  actuals) 

eval  (  rator  (e)  ,  a) 

evlis  (  rands  (e)  ,  a) 
-if  (e)      then 
(  cond(e),  a)  then  eval(  t-branch (e) ,  a) 
al (  f-branch(e),  a)  endif 


call  (e) 
losure  = 
ctuals  = 


and  rec  evlis   =   proc  (L, a)  begin 
if  null  (L)  then  <> 
else  cons  (  eval  (L [11  ,a)  ,  evlis  (  rest  (L)  ,  a )  )   endif   end 

and  rec  apply  =  proc (  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  pairlis(  bvs(abs),  actuals,  ep(closure))  in 
eval (  body  (abs)  ,  env)   end 

and  apply-prim  =  proc(f,x)  begin 

if     f='first'  then  first(x[l]) 

elsif  f='cons'   then  const  xfll,  x[21  ) 

elsif  ... 

endif  end 
in  ... 

Figure  4.   A-List  Eval 
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The  interpreter  is  very  similar  to  the  interpreters  used  for  LISP 
and  similar  languaqes.  To  clarify  its  operation,  several  exam- 
ples will  be  presented.  In  these  examples  we  will  trace  the 
invocations  of  'eval'  and  'apply'  and  occasionally  other  func- 
tions . 


EXAMPLE  1:   reduction  of  >xy {cons (y ,x) } (<2  3>,  i). 

In  the  list  representation  this  is: 
E  =  < 'call'  F  A> 
F  =  < ' lambda '  < • x'  ' y •>  3> 
B  =  <'prim'  'cons'  P> 
P  =  <<'var'  'y'>  <'var'  'x'>> 
A  =  «"const'  <2  3>>  <'const'  1>> 

Eval (E,  <>)  : 
closure  =  evai(F,<>)  =  ('closure'  F  <>> 
actuals  =  evlis(A,<>)  =  <<2  3>  i> 
apply(  closure,  actuals  ): 
abs  =  F 
env  =  pairiis(  <'x'  'y'>,  actuals,  <>  ) 

=  << 'x'  <2  3>>  < 'y'  x>> 
eval (3 , env)  : 
actuals  =  eviis(  <<'var'  'y'>  <'var'  'x'>>,  env  ) 

=  <i  <2  3>> 
appiy-prim(  'cons',  <i  <2  3>>  ): 
cons(  x,  <2  3>  )  =  <x  2  3> 
EXAMPLE  2:  Reduce 

let  i  =  3  in 

let  f  =  >x{  prod(x,i)  }  in 
let  i  =  2  in 
f  (i) 

To  translate  this  to  list  representation  it  is  necessary  to  first 
eliminate  syntactic  sugar: 

Xii   Xi{  Xi{    f(i)  } (2) } (  Ax{prod(x,i) }  ) } (3) . 


Notice  that  by  doinq  a  hand  reduction  of  this  we  can  determine 
that  the  correct  reduction  is  6.  For  the  sake  of  this  example  we 
will  assume  that  'eval'  can  evaluate  the  orimitive  application 
'prod',  which  multiplies  two  numbers. 
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I 
F 

J 

X 

P 


=  < 'call'  I 

=  <■ lambda' 

=  <  '  lambda' 

=  <  '  lambda ' 

=  <  '  lambda ' 


<<'const'  3>> 
<  '  l  '>  < 'call  ' 
<•  l'>  <'cail' 
< '  1  •>  < 'call  * 
< ' x'>  P> 


> 

F  <X>>  > 

J  << ' const ' 
<  * var  '  •  l  '> 


2>>  >> 

<< 'var ' 


'  i  '  >>  >> 


=  <'prim'  'prod'  <<'var'  'x*>  <'var'  'i'>>  > 


<>> 


X  <<  '  l  '  3>>  > 


3>>  > 


Eval (  S,  <>  )  : 
closure  =  <'ciosute'  I 
actuals  =  <3> 

appiy(  closure,  actuals  ): 
abs  =  I 

env  =  <<  '  i  '  3>> 

evai(  <'caii'  F  <X>>,  << '  i '  3>>  ): 
closure  =  ('closure'  F  <<*i'  3>>  > 
actuals  =  avlis(  <X>,  <<'i'  3>>  ) 

=  <C>   where   C  =  ('closure' 
appiy(  closure,  actuals  ): 
abs  =  X 

env  =  <<  '  l  '  C>  < ' l '  3>> 
evai(  <'call'  J  <<'const'  2>>>,  env 
closure  =  ('closure'  J  <<'l'  C>  <'i 
Actuals  -    <  2  > 

appiy(  closure,  actuals  ): 
abs  =  J 

env  =  <<'i'  2>  <"l'  C>  <'i'  3>> 
eval  (  <'cali'  <*var'  'l'>  <<'var'  'i'>>  >, 
closure  =  evai(  <'var'  'l'>,  env  )  =  C 
actuals  =  <2> 
apply(  closure,  actuals) : 
abs  =  X 

env  =  pairlis(  <'x'>,  <2>, 
=  pairlis(  < ' x'>  ,  <2> , 
=  << 'x'  2>  < '  l  '  3>> 
eval (  P ,  env  ) : 
actuals  =  eval  (  <<'var' 

=  <2  3> 
prim-appiy(  'prod',  <2  3>  ) 
prod(2,3)  =  6 


env  )  : 


ep( closur  e)  ) 
<<'  i'  3>>  ) 


x'>  < "var '  '  i  '>>  ,  env  ) 


Do  the  reduction  by  hand  to  be  sure  you  see  that  this  is 
right  answer. 


the 


T  .  4  . 1 7   replacement  of   var  iables   by   £  ixed 

that   our   current  interpreter  spends  a  lot  of  its 


locat  ions  .   Observe 
time  searching 


association  lists  for  the  values 


of   variables 
environment  ' a 


That  is,  the 
evaluation  of  <'var'  'x'>  in  the  environment  'a'  requires  search- 
ing 'a'  for  a  pair  whose  first  element  is  'x'.  Such  searching  is 
expensive  on  most  computers,  so  we  will  develop  a  method  of 
interpreting  the  lambda  calculus  which  does  not  require  it.  In 
particular,   we   will   replace   searching   by  array  subscripting, 


61 


which  is  much  more  efficient.  we  will  develop  the  Drocess  for 
single  variable  abstractions  initially  and  later  extend  it  for 
multiple  variables.  Consider  an  abstraction  '>x{E}'  in  some 
environment  '<...>'.  The  closure  formed  from  evaluatinq  this 
abstraction  will  be 

<'closure'  <'lambda'  < '  x  '  >  E>   <...>  >. 


When  this  closure  is  applied  to 
tion  will  always  take  the  form 


an  ooerand  value 


its   evalua- 


eval(  5,  «'x'  u> 


•  >  ) 
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the  static  distances  of  the  variables  from  their  definitions  are 
indicated.  For  'f'  it  is  2,  for  'x'  it  is  1,  for  the  leftmost 
'i'  it  is  1  and  for  the  rightmost  'i1  it  is  2.  Since  we  know 
where  each  variable  occurs  in  the  association  list,  we  can 
replace  expressions  of  the  form  <'var'  'x'>  with  expressions  of 
the  form  <'var'  n>  where  n  is  the  position  of  variable  'x'  in  the 
environment.  This  value  n  will  be  called  the  vn  or  variable 
position ,  as  indicated  in  the  new  structure  declaration  for  vari- 
ables : 

structure  var:  (vp) 

Since  we  no  longer  use  the  variable  names  to  look  them  up  in  the 
environment,  we  can  eliminate  them  and  represent  the  environment 
as  a  list  of  values  rather  than  an  association  list.  For 
instance  the  association  list 


<  <'x'  2>  <'y'  'Monterey'>  <'z'  <0  1  2>>  > 
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will  be  simplified  to 

<  2  'Monterey'  <0  1  2>  >. 

Then,  looking  up  <'var'  n>  in  environment  'a'  is  simply  accom- 
plished by  a[nl.  Since  variables  are  no  longer  needed,  the  bound 
variable  list  can  also  be  eliminated  from  the  representation  of 
abstractions.   For  instance  ">x{ cons (x , <> ) } '  is  represented  by 

<'lambda'  <'orim'  'cons'  <'var'  1>  <'const'  <>  >>  >. 

The  new  structure  definition  for  abstractions  is: 

structure  lambda:  (body) 

This  process  of  converting  variables  from  names  to  numeric  loca- 
tions is  one  that  is  usually  Derformed  by  a  translator  or  com- 
piler. Since  we  are  translating  bv  hand  from  the  lambda  calculus 
to  its  list  representation,  we  must  do  this  counting  ourselves. 
It  is  generally  true  of  programming  language  implementations 
that,  as  we  have  done  here,  the  run-time  efficiency  of  a  program 
can  be  increased  by  doing  more  work  at  compile  time. 

There  are  only  a  few  simple   changes  necessary   to   convert 

'eval'   to   use  the  new  numeric  variables  --  all  simplifications. 

The  rule  for  'var's  is  simply  altered  to  subscript  the  requred 
value  out  of  the  environment: 


elsif  is-var  then  a[vp(e)1 

The  only  other  change  is  to  the  'apply'  procedure:  since  environ- 
ments are  simple  lists  of  values  the  environment  of  evaluation  is 
constructed  by  appending  the  operand  to  the  front  of  the  environ- 
ment of  definition. 

and  rec  apply  =  proc (  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  append (  actuals,  ep(closure)  )  in 
eval(  body(abs),  env)   end 

To  clarify  these  ideas  we  will  trace  the  evaluation  of  the  lambda 
expression : 

>i{  Xf{  XH    f(i)  1(2)  }  (  Ax{prod(i,x)  }  )  }(3) 

This  is  represented  by  the  list: 
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E  =  <'caill  I  <<'const'  3>>  > 

I  =  <'lambda'  <,cali'  F  <X>>  > 

F  =  <'iambda'  <'caii'  J  <<'const'  2>>  >> 

J  =  <'iambda'  <'call'  <'var'  2>  «'var'  x>>  >> 

X  =  <• lambda'  P> 

P  =  <'prim'  'prod'  «'var'  2>  <'var'  x>>  > 


Evai (  E,  <>  )  : 
apply(  <'closuLe'  1  <>>,  <3>  ): 
env  =  append(  <3>,  <>  )  =  <3> 
evax(  <lcall'  F  <X>>,  <3>  ): 

Evaluation  proceeds  much  as  beroie,   until   the   stage   when   the 
application  t(i)  must  be  evaluated: 

eval(  <*call'  <'var'  2>  «'var'  1>>  >,  <2  C  3>  ): 
closure  =  eval (   <'var'  2>,    <2  C  3>  )  =  C 
actuals  =  evlis(  <<'var'  i>>,  <2  C  3>  )  =  <2> 
apply(  C,  <2>  ) : 
env  =  append(  <2>,  <3>  )  =  <2  3> 
eval (  P,  <2  3>  ) : 
actuals  =  evlis(  <<»var'  2>  <'var'  i>>,  <2  3>  ) 

=  <3  2> 
prim-appiy(  'prod' ,  <3  2>  )  =5 


1.4.18  static  nesting  level .  The  approach  used  above  is  based 
on  the  replacement  by  the  translator  of  variable  names  by  numbers 
indicating  the  static  distance  of  the  use  of  the  variable  from 
its  definition.  This  number  will  vary  from  one  use  of  a  variable 
to  another.   For  instance,  in 

Ax{  const  x,  >y{  cons(  x,  append(y,y)  )  }(<A  3>)  )  } (C) 

the  first  use  of  'x'  will  be  translated  by  <'var'  1>  while  the 
second  use  of  'x'  will  be  translated  by  <'var'  2>.  The  transla- 
tion process  would  be  a  little  simpler  if  a  single  number  was 
always  associated  with  all  uses  of  a  given  variable.  We  can  do 
this  by  using  the  static  nesting  level  of  the  definition  of  the 
variable   as   this   number.    The   static   nesting   level   of  the 
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definition  of  a  variable  is  one  more  than  the  number  of  scopes  in 
which  that  definition  of  the  variable  is  nested.  In  the  diagram 
below,  the  static  nesting  levels  of  the  variables  are  indicated: 
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let  rec  apply  =  proc (  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  append (  ep(closure) ,  actuals  ) 
eval (  body (abs),  env)   end 


in 


The  translation  of  lambda  expressions  into  the  list  representa- 
tion is  simplified  since  a  variable  is  always  translated  in  the 
same  way 


The  translation  of  our  previous  example  is 


J  =  <'iambda'  <*cali'  <'var'  2>  <<*var'  3>>  >> 
P    <'ptim'  'prod'  <<'var'  i>  <'var'  2>>  > 


EXERCISE:  Trace  the  evaluation  oi  this  list. 


■»  65  -» 


1.4.19  multiple  parameters .  To  keen  the  discussion  simple,  we 
have  only  been  discussing  the  implementation  of  abstractions  and 
applications  with  a  single  parameter.  T»'e  will  now  extend  our 
implementation  to  handle  more  than  one  parameter. 


In  our  current  implementation  (using  static  nesting 
the  environment  is  represented  by  a  list  of  the  form 


levels) 


<v 


vn> 


static   nesting 


where  v-  is  the  value  of  the  variable  bound  at 
level  1.  To  handle  multiple  parameters  we  will  simply  replace 
each  of  these  values  with  a  list  of  the  values  bound  at  each 
static  nesting  level.   That  is,  an  environment  has  the  form 


<ar-  ar 


«n> 


where  each  ar^  is  called  the  activation  record  (or  call  frame) 
for  static  nesting  level  i.  An  activation  record  is  defined  to 
be  all  of  the  information  relevent  to  a  call  of  a  function.  Fach 
activation  record  has  the  form 


<v- 


V- 


m 


where  the  v^s  are  the  values  of  the  variables  declared  at  the 
static  nesting  level  corresponding  to  the  activation  record.  To 
access  a  variable  it  is  now  necessary  to  use  two  coordinates, 
(ep,vp)  ,  where  the  envi ronment  part  (ep)  is  the  static  nesting 
level  of  the  activation  record  containing  the  variable,  and  the 
var iable   part   ( vp)  is  the  position  of  the  value  of  the  variable 

we   are   in   the 


within  that 
envi  ronment 


activation  record.   For  example,  if 


<  <1  2  3>  <'&'  '  B'  'C*>  <4  'D'  <5  <S>  'E'>  > 

then  the  (eo,vp)  pair  (2,1)  will  refer  to  'V,  the  pair  (3,2) 
will  refer  to  '0'  and  the  pair  (3,3)  will  refer  to  <S  6>.  In 
particular,  if  'a'  is  the  environment,  then  'a[epl [vpl '  is  the 
value  of  the  variable  corresponding  to  the  pair  (ep,vp) .  In 
order  to  make  use  of  this  new  structure  for  the  environment,  it 
is  necessary  to  translate  variables  into  lists  of  the  form 

< ' var '  ep  vp> 

where  (ep,vp)  is  the  location  of  the  variable.  This  corresponds 
to  the  structure: 


structure  var:  (ep,  vp) 
Therefore,  to  handle  multiple  parameters,  the  rule  for  'var's   in 
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'eval'  must  be  changed  to: 

elsif  is-var(e)  then  ar[vp(e)l 
where  ar  =  a [ ep  (e) 1 

The  next  issue  to  be  addressed  is  the  construction  of  these 
environments  by  the  'apply'  procedure.  If  the  environment  of 
definition  from  the  closure  is 


<ar-^ 


ar  > 
n 


and  the  actual  parameters  of  the  application  are 


<v-  v0  • 


m 


then  the  environment  in  which  the   body   of   the   abstraction   is 
evaluated  should  be 


<ar 


ar„  <v-  v0  • • •  v  >> 

n    -l   ^       rn 


That  is,  a  new  activation  record,  ar  +  ]_  =  <v^  •••  v  >,  is  made  the 
new  last  element  in  the  environment.  If  ep'  is  the  environment 
of  definition  and  'x'  is  the  actual  oarameter  list,  then 


consR  (  ep,  x  ) 

where  consR  =  proc(L,x){  append (  L,  cons(x,<>)  )  } 

will  construct  the  environment  of  evaluation.   The   aopropr iately 
modified  'apply'  is: 

let  rec  apply  =  proc(  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  consR(  ep(closure),  actuals)  in 
eval (  body (abs) ,  env  )   end 

and  consR  =  proc(L,x){  apoend  (  L,  cons(x,<>)  )  } 

The  complete  'eval'  is  shown  in  the  next  figure.   To   demonstrate 
the  operation  of  the  new  'eval' ,  we  will  trace  the  reduction  of 

>xy{  Xz{    z*z  +  x  }  (x+y)  }  (2,3) 

First  we  translate  the  lambda  expression  into  our  list   represen- 
tation, numbering  the  lambdas  as  before: 

<call  <lambda(l) 

<call  <lambda(2)  <prim  sum  <prim  prod  <var  2  1>  <var  2  ] 

<var  1  1>>  > 
<prim  sum  <var  1  1>  <var  i  2>>  >> 
<const  2>  <const  3>> 
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let  rec  Eval  =  proc(e,a)  begin 

if     is-const(e)   then  const-val(e) 
elsif  is-var  (e)     then  ar[vp(e)l   where 

then  closuref  e,  a) 
then  apDly-Drim(  rator(e) 
evlis  (  rands (e)  ,  a) 

then  apply(  closure,  actuals) 
eval  (  rator (e)  ,  a) 


elsif 
elsi  f 


i  s-var  (e) 
i  s-*lambda  ( e) 
is-pr  in (e) 
where  actuals  = 
elsif  is-call  (e) 
where  closure  = 
and    actuals  = 
elsif  is- if (e) 

i  f  eval  (  cond  (e) 
else  eval  (  f-branch(e) 
endif  end 


ar  =  a [ep(e) 1 
actuals) 


evlis (  rands  (e)  ,  a) 

then 
,  a)  then  eval  (  t-branch(e) 
a)  endif 


a) 


and  rec  evlis   =   proc(L,a)  begin 
if  null  (L)  then  <> 
else  cons  (  eval  (L [ 1 1  , a)  ,  evlis ( rest (L)  , a )  )   endif   end 

and  rec  apply  =  nroc(  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  consR(  ep(closure),  actuals)  in 
eval (  body(abs),  env)   end 

and  apply-prim  =  proc(f,x)  begin 

if     f='first'  then  first(x[l]) 

elsif  f='cons'   then  cons(  xTll ,  x[2]  ) 

elsif  ... 

endif  end 
in  ... 

and  consR  =  proc(L,x){  append  (  L,  cons(x,<>)  )  } 

Figure  5.   Eval  for  Fixed-location  Variables 


Here  we  see  that  'x',  'y'  and  'z'  have  been  translated  as  ' <var  1 
1>',  '  <var  1  2>'  and  '<var  2  1>',  respectively,-  on  the  basis  of 
their  static  nesting  levels  and  their  positions  at  that  level, 
i.e.  their  (ep,vp)  coordinates.   The  trace  follows: 
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E 

X 

z 
s 
p 


<'call'  X 

< ' lambda ' 


<<  '  const. ' 
<'cali'  Z 


2>  < ' const ' 
<S>>  > 


3>>  > 


=  ('lambda'  <'pnm'  'sum'  <P  <'var'  I  I>>  >> 
=  <*pnm'  'sum'  «'var'  i  I>  <'var'  I  2>>  > 
=  <'pnm'  'prod'  «'var'  2  i>  <'var'  2  i>>  > 


Evai (  E,  <>  ) : 
appiy(  ('closure'  X  <>  >,  <2  3>  )  : 
env  =  consR(  <>,  <2  3>  )  =  <<2  3>> 
evai(  <'call'  Z  <S>>,  <<2  3>>  ): 
actuals  =  evlis(  <<'pnm'  'sum' 

«'vat'  i  I> 
=  <  sum (2, 3)  >  =  <5> 


2>>  >>,  <<2  3>>  ) 


appiy( 
env  = 
eval  ( 


<' closure 


consR ( 
< ' pr lm 


<<2 


Z  <<2  3>>  >, 
3>>,  <5>  )  = 


sum 


<P  <'var 


actuals  =  evlis(  <P 


<5> 

<<2 

I  1 '. 
1>> 


)  : 

3>  <5>> 


=  <  evai(P,<<2  3><5>> 


>>  >, 
<<2 
> 


<<2  3>  <5>>  ) 
3>  <5>>  ) 


It  is  now 
3><5>>)  . 


necessary 


compute   the   subexpression,   eval(P,<<2 


evai (  ?,  <<2  3>  <5>>  ) : 
actuals  =  evlis(  <<'var'  2  I>  <'var'  2  i>>, 

<<2  3>  <5>>  ) 

=  <5  5> 

prim-apply(  'prod',  <5  5>  )  =  25,  hence, 
actuals  =  <25  2> 
prim-appiy(  'sum',  <25  2>  )  =27 


You  will  recall  that  there  were  two  possible  versions  o 
single-parameter  'eval':  one  which  used  static  nesting  leve 
one  which  used  static  distances.  There  are  also  two  po 
versions  of  the  multiple-parameter  version  of  'eval':  we  c 
either  static  nesting  levels  or  static  distances.  When  we 
tigate  implementations  of  the  lambda  calculus  further,  lat 
will  find  that  there  are  circumstances  when  it  is  better  t 
the  static  distance  and  other  circumstances  when  it  is  bet 
use  the  static  nesting  level.  These  are  similar  to  imple 
tion  techniques  called  "static  chains"  and  "displays",  whi 
discussed  later. 

EXERCISE :  Translate  the  lambda  expression 

>xy{  Xz{    z*z  +  x  }  (x+y)  }  (2,3) 


f  the 
Is  and 
ssible 
an  use 
inves- 
er  ,  we 
o  use 
ter  to 
menta- 
ch  are 


into  the  list  reoresentat: 
static  nesting  levels. 


on  using  static   distances   instead   of 
the  aoprooriate  changes  to  'eval'  so 
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will  work  correctly  with  'var's   containing   static   dis- 


that  it 

tances   and   show 

above  expression. 


that  it  works  by  tracing  the  evaluation  of  the 


'J  - 


Chapter  5 


I  .5   Runtime  Organization 

I  .5.1   Goals  Defined 

In  this  chapter  we  will  study  the  stack  implementation  of 
the  extended  lambda  calculus.  That  is,  we  will  study  how  FLC  can 
be  translated  into  the  instructions  of  conventional  computers  by 
usinq  the  data  structure  known  as  a  stack .  Since  all  block- 
structured  languages,  when  stripped  of  their  syntactic  sugar,  are 
essentially  the  lambda  calculus,  you  will  be  learning  how  to 
implement  these  lanquages.  (This  important  class  of  languages 
includes  Algol,  Pascal,  PL/I  and  Ada.) 


I  .5 


Stacks 


The  data  structure  used  on  most  computers  for  implementing 
block-structured  languages  is  the  stack .  Stacks  derive  their 
name  from  the  push-down  stacks  that  are  often  used  for  dispensing 
plates  in  cafeterias  (figure  1). 


Figure  I.   The  Original  Push-Down  Scack 


with  these  devices,  each 

time  a  p 

late  is 

removed 

from   the   top, 

the   stack   p 
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bring 

the  next 

plate  to  the  too.   Con- 

versely,  whenever  a  plat 

e  is  placed  on  th 

e  too  of 

the   stack,   it 

Dushes   down 

the  plates 

already 

there . 

Thus,  a 

particular  plate 

can  be  pushed 

onto  the  stack,  and 

have  other  olates  pushed  on  top 

of   it,   thereby  hiding 

it.   But 

if  these 

plates 

are  later  popped 

off,  then  the 

plate  we  started  wi 

th  will 

again  be 

at  the   too   of 

the  stack.   This  Drooert 

y,  being 

able  to 

save  thi 

ngs  (or  informa- 

tion)  by  push 
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a  stack  , 
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he  stack 

data   structure 

particularly 

valuable 

in   programming 
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I  .5.3   Postfix  Instructions 

we  have  seen  how  expressions  can  be   written 
form.   For  instance, 


in   functional 


can  be  written 


x  +  ab(y-z) 


sum  (  x,  prod (  orod(a,b),  dif(y,z)  )) 

when  an  expression  such  as  this  is  written  without  parentheses  it 
is  call  prefix  notation  o  r  Pol ish  notation  (after  Jan  fe 
ukasiewicz,  the  Polish  logician  who  invented  it).  The  above 
expression  written  in  prefix  notation  is: 


+  x 


a  b  -  v  z 


One  of  the  important  orooerties  of  Polish  notation  (and  the  rea- 
son it  was  invented)  is  that  it  is  never  necessary  to  use 
parentheses  with  it;  it  is  ofen  called  parentheses  free  nota- 
tion . 

The  reason  Polish  notation  is  also  called  prefix  notation  is 
that  the  operator  is  written  before  (pre-)  its  operands.   E.g. 

+  x  y 

The  usual  mathematical  convention  is  called  infix  notation 
because  the  operator  is  written  between  (in-)  its  operands: 

x  +  y 

It  should  be  obvious  that  if  we  wrote  the  operator  after  its 
operands,  then  we  would  be  writing  in  postfix  or  reverse  polish 
notation.  Reverse  Polish  notation  is  more  important  to  computer 
scientists  than  Polish  notation  because  reverse  Polish  can  be 
evaluated  easily  by  using  a  stack. 

You  may  be  familiar  with  "PPM"  (or  Reverse  Polish  Notation) 
calculators,  such  as  those  manufactured  by  Hewli tt-Packard  and 
National  Semiconductor.  with  these  calculators  expressions  to  be 
evaluated  are  entered  in  postfix  notation  and  temporary  results 
are  held  in  a  stack.   ^or  instance,  to  calculate 


2  +  5 


10, 


which  is  postfix  notation  is 

2  5  10  *  +, 


-  11 


we  would  hit  the  keys: 

GD    rwn    CD    rwn    en    ED 


czi  m 


The  follwinq  diagram  shows  how  the  stack  holds   the   intermediate 
results . 


2  ENT 


5  ENT 


.0 


10 

5 

5 

50 

2 

2 

Z 

2 

Notice  how  the  stack  holds   the   operands   before   the   operation 
(e.g.  5  and  10)  and  the  results  after  the  operation  (e.g.  50). 


I  .5.4   The  L-Machine  Architecture 

We  will  now  investigate  a  computer  with  a  stack  architec- 
ture, i.e.  a  computer  that  uses  a  stack  for  the  evaluation  of 
postfix  instructions.  Although  the  L-Machine  is  not  a  real  com- 
puter, it  is  essentiallv  a  simplification  of  several  commercially 
available  machines. 


The  L-Machine  has  three 
tions) ,   called  SP,  ED  and  IP, 


registers  (high  soeed 


memory   loca- 
and  a  memory  addressed  by  consecu- 
tive natural  numbers  that  can  hold  both   data   and   instructions 
The  register  names  are  mnemonic: 


SP   -   Stack  Pointer 

EP   -   Environment  Pointer 

IP   -   Instruction  Pointer 

The  SP  register  holds  the  address  of  the  top  of  the  stack,  the  EP 
register  holds  the  address  of  the  current  activation  record 
(explained  further  later)  and  the  IP  register  holds  the  address 
of  the  next  instruction  to  be  executed.  The  L-Machine's  storage 
architecture  is  summarized  in  the  following  figure. 


Reaisters 


SP 

EP 


001 
002 
003 
004 

005 

00* 


Memory 


Figure  2.   L-Machine  Storage  Architecture 


-73- 


The  L-Machine  has  some  25  instructions  that  it  is  able  to 
execute.  we  will  discuss  each  of  these  in  the  following  para- 
graphs and  indicate  their  operation  with  diagrams. 

1   PUSH.   The  'PUSH'  operation   pushes   a   constant   value 


onto   the   stack 


That   is,  if  k  is  any  constant  (i.e., 


string,  Boolean  or  list),  then  'PUSH  k'   will   increment 


number , 
the   SP 


register   and  store  k 
diagramatic  form: 


in  the  memory  location  addressed  by  SP.   In 


=  > 


k 


Stack 


PUSH  k 

2   PUSHEP.   The  "PUSHEP"  operation  pushes  the  current  con- 
tents of  the  EP  register  onto  the  stack: 


EP 


EP 


=  > 


PUSHEP 


3  POP.  The 
top  of  the  stack, 
from  the  stack  and  discard 


'POP'  instruction  discards  elements  from   the 
That  is,  'POP  k'  will  pop  the  too  k  elements 
them.   E.g.. 


stack  and  places  it  in  the  EP  register 

epT 


EP 


b   => 


SETEP 


5  MARK .  The  'MARK'  operation  moves  the  current  contents 
of  the  SP  register  into  the  EP  register.  The  effect  of  this  is 
to  remember  the  location  of  the  current  top  of  the  stack. 
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MARK 

<5  COPY.  The  'COPY'  operation 
a  specified  location  of  the  stack, 
stack.  For  instance,  'COPY  3*  copies 
from  the  top  of  the  stack  and  pushes  it: 


copies  a  va 
and  places 
the   value 


ue  from   within 

t  on  top  of  the 
that   is   third 


(1) 
(2) 
(3) 
(4) 


=  > 


COPY  3 

7  SWAP.  The  'SWAP'  ooeration  exchanges  two  elements  of 
the  stack.  For  instance,  'SWAP  2,5'  swaps  the  second  and  fifth 
elements  from  the  top  of  the  stack: 


(1) 

(2) 
(3) 
(41 
(5) 


=  > 


SWAP  2,5 

3  PAIR.   The  'PAIR'  operation  combines  the  too  two   stack 

elements  into   one;   the   two  elements  become  the  left  and  right 

halves  of  the  resulting  value.   These  two  values  can  be  extracted 

by  'LEFT'  and  'RIGHT',  described  below. 


=  > 


PAIR 
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9   LEFT,  RIGHT.   The  'LEFT'  operation   extracts   the   left 
half  of  a  value  constructed  by  'PAIR': 


=  > 


LEFT 

The  'RIGHT'  operation  extracts  the  right  half. 

.10  VAL .  The  'VAL'  operation  access  the  current  contents 
of  a  location  in  memory.  The  'VAL'  operation  takes  an  address 
from  the  top  of  the  stack  and  reolaces  it  with  the  contents  of 
the  memory  location  at  that  address. 

Stack-\ 


Memorv 


VAL 


11   SET.   The 


'SET' 
location  to  a 


of   a  memory 

an  address  from  the  top  of 

memory   location  with  that  address. 

of  the  stack. 


operation  chanqes  the  current  contents 
specified  value.   It  takes  a  value  and 
the  stack  and  stores  the  value  in   the 
The  value  is  left  on  the  top 
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Stack 


> 


Memory 


J 


=  > 


SET 


12  ADD ,  SUB,  mul,  DIV.  These  ©Derations  perform  addi- 
tion, subtraction,  multiplication  and  division.  The  operands  are 
the  two  top  elements  of  the  stack,   which   are   replaced   by   the 


results  of 
lator . 


the  operation.   This  is  essentially  like  an  RPN  calcu- 


=  ^> 


x+v 


ADD 
(SUB,  MUL,  DIV  similar) 


Any  other  primitive  operations  with  which  we 
L-Machine  (such  as  the  relationals,  EQ, 
operate  analogously. 


i  sh 

to 

equip   the 

ME, 

IT 

etc . )  would 

13   IP.   The 
the   stack   is   'true' 
the  stack  and,  if  this  value  is 
tion  at  location  k  (by  placing  k 


'IF'  operation  performs  a  iump  if  the  top   of 

In  particular,  the  operation  'IP  k'  pops 

'true',  transfers  to  the  instruc- 

in  the  IP  register) .   If  the  too 


ot  the  stack  is  false  then  execution  continues  at  the  instruction 
which  follows  the  'IF'. 


IP 


b   => 


IP 


b=true 
b=f alse 


IF  k 
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14   IOTP.   The   'GOTO'   operation   transfers   control 
another  location  by  placing  its  operand  in  the  IP  register. 


to 


IP 


=  > 


IP 


GOTO  k 


OOI .   The  '001'  operation  is  an  "indirect  goto" 
top  of  the  stack  is  a  value  that  is  used  as  the 


15 
is,   the 

of  the  next  instruction  to  execute.   This  is  accomplished 
ping  the  stack  into  the  IP  register.   001  is  used  instead 
when  the  destination  address  must  he  computed  while   the 
is  running. 


IP 


IP 


b 


b   => 


001 


That 
address 
by  pop- 
of  GOTO 
oronram 


I  .5  . 

5   Activation  Record  Structure   As 

we  learned  in 

Ohapter  I. A 

the 

activation  record 

is  the  implementation  mechanism 

that  embo- 

dies 

the  idea  of  the  local  environment  o 

f  a  computation.   Activa- 

tion 

records   will  also  be  important  to 

our  compiled 

implementa- 

t  ion 

of  the  lambda  calculus,  so  in  this 

section   we 

will   study 

their 

implementation 

on   a   stack .    Y 

ou   will  remem 

ber  that  we 

defined  an   activation 

record   to   be 

all   of   the 

information 

relevent   to  a  call  of 

a  procedure.   In 

the  Eval  interpreter  this 

was  " 

ust  the  values  of 

the  bound  variabl 

es  of  the   function.    We 

will 

see   below   that 

in  the  compiled 

implementation 

additional 

information  must  be  included  in  the  activation  record. 

Oonsider  the  following   lambda   expression,   which   we   have 
already  investigated  several  times: 

let  i  =  3  in 

let  f  =  proc(x){  x*i  }  in 
let  i  =  2  in 
f  (i) 

This  can  be  represented  by  the  contour  diagram  in  figure  3.  In 
this  diagram  we  have  drawn  solid  arrows  from  each  contour  to  the 
statically  enclosing  contour.  These  arrows  are  called  static 
links .  A  static  cha  in  is  any  contiguous  sequence  of  static 
1  inks ,  for  instance  from  the  i  =  2  contour  to  the  f=A(xi}  contour 
to  the  i=3  contour.  what  the  static  chain  provides  is  a  search 
path  for  looking  up  variables.  For  instance,  if  we  are  executing 
in  the  environment  indicated  by  the  it  in  the  above  diagram,  and 
wish  to  evaluate  'i',  then  we  proceed  as  follows.   First  look   in 
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a. 


i   i  3 

\ 

---   ; 

,--  7"  - 

b 

f\J           X 

a 

*i- 

J 

c 

i   !i 

/r?; 

Figure  3.   Contours 

the  local  environment:   is 

defined  here,  so  follow  the 

ment:   is  it  defined  here?   Yes,  the  value  of  'i' 

hadn't   been   defined  here  we  would  have  followed 


t  defined   here?    Mo,   only   'x'   is 
static  link  to  the  enclosing  environ- 

is  3  .    If   it 
the  static  link 


and  continued  searching  in  the  staticallv  enclosing  environment. 

In  our  compiled  implementation  of  the  lambda  calculus, 
activation  records  will  be  stored  in  a  stack.  we  will  use  static 
links  to  find  our  wav  from  one  activation  record  to  the  next. 
For  instance,  when  we  begin  executing  ' f  (i)  '  in  contour  (c)  ,  the 
stack's  structure  will  be: 


Figure  4.   Before  call  to  f 

The  activation  records  correspond  exactly  to  the  contours  encoun- 
tered in  following  the  static  chain  from  'f(i)'.  The  5P  register 
always  points  to  the  beginning  of  the  static  chain.  Mow,  suppose 
we  call  the  function  bound  to  'f'.  This  amounts  to  entering  the 
contour  (d  )  to  execute  'x*i'.  The  activation  record  for  'f  will 
be  pushed  onto  the  top  of  the  stack.  Mote,  however  that  the 
static  chain  reflects  the  correct  environment  for  'x*i': 
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t?D 


figure  5.   Inside  f 

In  particular,  when  we  come  to  evaluate  'i',  we  will  follow  the 
static  chain  to  activation  record  (a),  which  binds  'i'  to  3. 
When  the  function  'f '  is  exited  the  activation  record  (d)  must  be 
deleted  from  the  stack  and  the  situation  restored  to  that  of  fig- 
ure 4.  To  do  this  it  is  necessary  to  regain  access  to  activation 
record  (c) ,  the  activation  record  of  the  caller  of  ' f*.  Doing 
this  requires  another  link,  the  dynamic  link ,  from  each  activa- 
tion record  to  its  caller.  The  sequence  or  dynamic  links  is 
called  the  dynamic  chain .  In  figure  5  we  see  the  same  situation 
as  in  figure  5  (i.e.  inside  f)  exceDt  that  the  dynamic  chain  is 
shown . 


^p 


Figure  6.   Inside  f,  with  dynamic  chain 
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Notice  that  the  dynamic  link  always   points   to   the   next   lower 
activation  record  in  the  stack. 


So  far  we  have  seen  that  the  activation  record  contains 
three  oieces  of  information:  the  values  of  the  bound  variables, 
the  static  link  and  the  dynamic  link.   There  is  one  other  type  of 


information   that 
temporaries.   urhen 
expressions  we  saw 
to  ooerate  on  them 
here . 


is  useful  to  include  in  the  activation  record: 

we  discussed  the  stack  evaluation   of   postfix 

that  the  stack  holds  operands  until  it  is  time 

We  will  use  the  stack  for  the   same   puroose 


The  actual  format  we  will  adopt  for  activation  records  is 
not  the  same  as  we  have  investiqated  so  far.  The  differences  are 
not  important,  however;  we  have  merelv  reorganized  the  fields  of 
the  activation  record  to  make  it  more  convenient  to  access  them 
with  the  instructions  of  the  L-Machine.  If  we  were  compiling  the 
lambda  calculus  for  some  other  machine  then  some  other  arrange- 
ment might  be  better.  The  important  thing  is  the  information  the 
activation  record  contains,  irrespective  of  its  arrangement: 

*  access  to  local  environment  (values  of  bindings) 

*  access  to  alobal  environment  (static  link) 

*  access  to  caller  (dynamic  link) 

*  temporaries 


This  information  must  be  in  any  activation  record. 
will  use  for  the  L-Machine  is  shown  in  figure  7. 


The  format  we 


temocra  r i  es 


static  link 


dynamic  link 
i 

er>  '   io 


parameter  n 


parameter  1 


Stack- 
Figure  7.   Activation  Record  Format 


I  .5 


Translation  to  L-Code 


-  81  - 


In  this  section  we  will  discuss  the  L-Code  (L-Machine 
instruction)  translations  tor  each  construct  in  the  extended 
lambda  calculus.  To  aid  this  discussion  we  will  use  the  notation 
Afe]  to  denote  the  L-Code  translation  of  the  lambda  expression  e. 
For  instance, 


At  25  ] 


PUSH  25 


The  translations  we  will  investigate  in  the  rest  of  this  section 
are  not  unique;  different  machines  would  suggest  different  code 
sequences;  there  are  even  different  ways  of  accomplishing  the 
same  thing  on  the  L-Machine.  The  important  issue  is  not  the  par- 
ticular instructions  presented  here,  but  rather  the  information 
flow  required  to  execute  the  lambda  calculus  constructs.  Since 
the  lambda  calculus  forms  a  deep  structure  for  most  programming 
languages  we  are  essentially  studying  the  implementation  methods 
for  most  programming  languages. 

1  Constants  The  translation  of  variables  is  the  sim- 
plest, since  all  we  have  to  do  is  to  oush  the  constant  on  the 
stack.   For  instance, 


A?25]   =   PUSH  25 
Af'hat']   =   PUSH  *hat' 
A(<i  <'hat'  2>>]   =   PUSH 


<1  <'hat'  2>> 


or  in  general,  for  any  constant  c, 

Ale]       =   PUSH  c 

2  Var  iables  In  the  discussion  of  the  Fval  interpreter  we 
saw  the  use  of  (eo,vp)  pairs  to  locate  variables  within  the 
environment.  We  will  do  the  same  with  our  compiled  implementa- 
tion: the  eD  will  locate  the  activation  record  holding  the  vari- 
able and  the  vp  will  locate  the  variable  within  that  activation 
record.  The  static  distance  method  of  measuring  the  ep  will  be 
used  . 


First,  consider  how  we  get  to  the  activation  record  in  which 
the  variable  resides:  if  ep=i  then  the  variable  resides  in  the 
current  activation  record,  which  is  pointed  to  by  the  FP  regis- 
ter. If  ep=2  then  the  variable  resides  in  the  next  most  enclos- 
ing activation  record,  which  we  reach  by  followina  one  link  of 
the  static  chain  form  the  current  activation  record.  If  ep=3 
then  we  must  follow  two  links  of  the  static  chain.  In  general, 
we  must  follow  ep-1  links  to  get  to  the  activation  record  con- 
taining variable  (ep,vp). 

Now  let  us  consider  the  L-Code  required  to  follow  the  static 
chain.    Our   goal   will   be  to  get  the  address  of  the  activation 
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record  ep  onto  the  top  or  the  stack.   Consider  the  case  ep=I.   In 
this  case  the  activation  record  is  the  current  one,  so 

PUSHEP 

will  push  its  address  onto  the  stack. 

Now  consider  the  case  ep=2;  here  we  must  follow  the  static 
chain  one  link.  Recall  that  both  the  EP  register  and  the  static 
links  always  point  to  the  static  link  field  of  an  activation 
record.   See  figure  3. 

EP 


Figure  3.   The  Static  Chain 

Hence,  after  performing  PUSHEP  the  too  of  the  stack  is  the 
address  of  the  static  link  for  the  current  activation  record.  We 
can  use  VAL  to  load  the  contents  of  this  location,  i.e.  to  get 
the  address  of  the  next  activation  record  in  the  static  chain. 
Hence , 

PUSHEP 
VAL 

will  leave  on  the  top  of  the  stack  the  address  of  the  eo=2 
activation  record. 

Following  the  same  reasoning  we  can  see  that   if   ep=3   then 
the  address  of  the  activation  record  is  computed  by: 

PUSHEP 

VAL 

VAL 


In  general , 
distance  ep 


the  code  to  access  the  activation 
is  PUSHEP  followed  by  ep-i  VALs . 


record   at   static 
We  will  write  this: 
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P'JSHEP 
(ep-1)  *  {  VAL 

'*'e  have  seen  how  to  use  the  ep  part  of  a  variable's  coordinates 
to  qet  to  the  activation  record  in  which  it  resides.  We  will  now 
investiqate  the  use  of  the  vo  part  to  locate  the  variable  within 
that  activation  record.  Figure  9  shows  an  activation  record  with 
several  measurements  indicated. 


vo 

A. 


Temos 


SL 


TL 


Dvo 


base 
base-? 

base-2-n+vo 
ba  se-2-n 


Figure  9.   Activation  Record  Distances 

If  base  is  the  base  address  of  the  activation  record  (i.e.  the 
address  of  its  static  link)  then 

base-*2-n~vD 

is  the  address  of  the  vo-*th  variable  in  that  activation  record. 
We  can  rewrite  this  as 

base  -  (2+n-vp) 

Notice  that  (2+n-vp)  is  a  constant  that  depends  only   on  the   vp 

coordinate   of   the  variable  and  the  number  of  variables  bound  at 

lexical  level  ep.  We  will  call  this  latter  quantity  n9p  and 
define 

6(ep,vp)  =  2+nep-vp 

Thus  the  address  of  the  variable  with  coordinates  (ep,vp)  is 

baseetD-6  (ep,vp) 

It  is  very  easy  for  a  compiler  to  compute  the  quantity  6(ep,vp) ; 
it  need  only  keep  track  of  the  number  of  variables  declared  at 
each  lexical  level. 
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Now  we  are  ready  to  our  together  the  two  parts  of  the   vari- 
able accessing  mechanism.   To  get  the  address  of  variable  (ep,vp) 

the  address  of  the  activation   record   at   static 
This  is  exactly  what  is  computed  by: 


we  need  base 
distance  ep. 


ep 


PUSHEP 

(ep-I)  *  {  VAL 

To  get  the  address  of  the  variable  we  must  subtract  S"(ep,vp): 

PUSH  6  (eo,vp) 
SUB 

Therefore  the  code  for  accessing  the  variable  with  coordinates 
(eo,vp)  and  leaving  its  value  on  the  stack  is: 

Var  ep,vp   = 

PUSHEP 
(ep-I)  *  {  VAL 

PUSH  6 (ep,vp) 

SUB 

VAL 

We  have  given  this  sequence  of  instructions  the  "macro"  name  Var 
because  it  occurs  so  frequently.  Macros  like  this  are  sometimes 
called  code  skeletons .  por  example,  if  the  coordinates  for  'x1 
are  (3,2)  and  n3=3  then  the  code  for  accessing  ': 


is 


AM   =   var 

PUSHEP 

VAL 

VAL 

PUSH  3 

SUB 

VAL 


3,2 


since  6(3,2)  =  2+n3-2  =  2+3-2  =  3. 


It  must  be  emphasized  again  that  the  L-Code  shown  here  is 
appropriate  to  the  activation  record  format  we  have  chosen.  If 
the  activation  record  format  were  different,  then  different 
instructions  would  be  required.  The  important  ideas  to  remember 
in  accessing  a  variable  with  coordinates  (ep,vp)  are: 


1)  Find  the  activation  record  holding  the  variable   by 
lowing  the  static  chain  for  a  static  distance  of  ep. 


fol- 


2)  Use  the  vp  coordinate  to  access  the  variable 
activation  record  found  in  step  (1). 


within   the 
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we  can  now  state  the  translation  rule   for 
with  coordinates  (eo,vp): 


var  iable 


Afv]   =   Var  eo,vo 


3   Applications 


Recall  that  the  steps  involved  in  evaluating   a   application 


are 


1)  Evaluate  the  operator. 

2)  Evaluate  the  operands. 

3)  Construct  the  environment  of  evaluation. 

4)  Evaluate  the  body  of  the  function  in  this  environment. 

The  code  that  we  produce  for  a  application  will  have   to   perform 
these  same  steps.   It  is: 

At  f  (ex en)  ]   = 

Alt] 


Ate  ] 

Call   n 

The  Call  macro  instruction  will  do  the  work  of  construct inq  an 
activation  record  for  the  new  environment  and  executing  the  func- 
tion in  that  environment  (steDs  (3)  and  (4)). 

EXAMPLE :  Compile   'mod  (7, 2)'.    Assume   the   coordinates   of 
'mod'  are  (3,1). 

A(  mod(7,2)  ]   = 

Atmod] 

Am 

AI2] 

Call  2   = 

Var  3,1 
PUSH  7 
PUSH  2 
Call  2 


As  noted  above,  the  Call  macro 
building  the  new  activation 
cedure.   Since  the  parameter  va! 


instruction  is  responsible  for 
record  and  for  entering  the  pro- 
ues  are  already  stacked,  only  the 


dynamic  and    static  link  parts  of  the  new  activation  record  remain 
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to  be  constructed.   The  steps  are: 

1)  Construct  dynamic  link. 

2)  Construct  static  link. 

3)  Install  the  new  current  activation  record. 

4)  Enter  the  function. 


Since  the  dynamic  link  must  preserve  the  state  of  the   caller   it 
has   two  parts:  an  eo  to  preserve  the  caller's  environment  and  an 


ip  to  preserve  the  next  instruction  to 
saved  by  constructing  a  closure: 


execute 


These   can   be 


PUSHEP 
PUSH  r 
PAIR 

where  r  is  the  address  of  the  next   instruction   following   Call; 
this  is  where  execution  of  the  caller  will 
procedure  returns.   This  leaves  the  stack 


resume  when 
n  the  state 


the  called 


DL 

Pn 

. 

PI 

f- 

-closure 

n+1 
n  +  2 


The  static  link  must  point  to  the  environment  of  definition  of 
the  procedure.  As  the  above  diagram  indicates,  the  (n+2)  posi- 
tion from  the  toD  of  the  stack  contains  a  closure  for  the  pro- 
cedure to  be  called  (this  resulted  from  evaluating  the  operator 
in  steD  (1)).  The  static  link  is  constructed  by  extracting  the 
left  half  (ep)  of  this  closure: 

COPY  n+2 
LEFT 

The  third  step,  installing  the  new  current  activation  record,  is 
accomplished  by  placing  the  address  of  the  new  activation  record 
into  the  EP  register.  Since  the  static  link  is  currently  at  the 
top  of  the  stack,  this  is  accomplished  bv: 

*!ARK 


This  leaves  the  stack  in  the  state: 
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SL 

nr. 

Pn 

, 

PI 

f- 

-closure 

*— % 

_■---■—  —    _ 

n+2 
n  +  3 


and  completes  construction  of  the  activation  record. 

The  fourth  step  is  to  enter  the  function.  The  address  of 
the  first  instruction  in  the  function  is  contained  in  the  closure 
at  position  (n+3)  in  the  stack.  Thus  transfer  into  the  function 
is  accomplished  by: 

COPY  3+n 

RIGHT 
GOI 

Putting  together  the  entire  instruction  sequence  for  Call  yields: 

Call  n   = 

I 

}  build  DL 


PUSHEP 

PUSH  r 
PAIR 

COPY  n+2 
LEFT 
MARK 

COPY  n+3 
RIGHT 
GOI 


r : 


build 

SL 
install  new  AR 
get  entry 

po  i  n  t 
enter  the  function 
the  return  location 


It  is  to  be  emphasized  again  that  the  specific  code  sequence 
shown  above  is  not  so  important  as  the  aeneral  steps  involved  in 
a  call: 

1)  Save  the  state  of  the  call  in  the  dynamic  link. 

2)  Make  the  static  link  from  the  ep  in  the  closure. 

3)  ^nter  the  function  at  the  location  determined  by  the 
ip  of  the  closure. 

EXERCISE :  Design  the  activation  record  format  for  a  computer  with 
which  you  are  familiar.  Write  the  sequence  of  instructions 
necessary  to  do  a  Call  on  this  machine. 

4   Abstractions 


an 


Recall  that  in  the  Eval  interpreter  the  proper  execution   of 
abstraction   was   ensured   by   packaging  it  together  with  its 
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environment  into  a  closure .  In  the  compiled  case  the  en  part  of 
a  closure  is  a  pointer  to  the  activation  record  of  definition  and 
the  ip  part  is  the  address  of  the  first  instruction  of  the  code 
for  the  abstraction's  body.   This  is  constructed  by: 

PUSHEP 
PUSH  k 
PAIR 

where  'k'  is  the  entry  address  of  the  function.  The  body  of  an 
abstraction  '>v-j_  •  •  •  vn{  E  }  '  is  translated  to: 


k: 


Am 

Return  n 

where  Return  is  a  "macro"  instruction  described  below.  Since  we 
do  not  want  the  function  body  to  be  executed  before  it  is  called, 
we  must  jump  over  it.  Therefore,  the  translation  of  an  abstrac- 
tion is : 


A(>Vn_  •  •  -V 

r   J 

n1 

E}] 

PUSHEP 

ep 

1 

PUSH  k 

ip 

} 

build  closure 

PAIR 

1 

GOTO  s 

} 

skip  body 

k:A(E) 

Return 

n 

s : 

The  Return  instruction  must  accomplish  the  following  tasks: 

1)  Pass  the  returned-value  from  the  callee  to  the  caller. 

2)  Restore  the  state  of  the  caller  from  the  dynamic  link. 

3)  Delete  the  callee's  activation  record. 

The  state  of  the  stack  before  the  Return  is: 


answer 

SL 

DL 

Pn 

. 

PI 

f-clcsure 

L-~.— -  __ v 

n+3 

n+4 


The  returned-value  ('answer'  in  the  above  diagram)  can  be   placed 
above   the   caller's   temporaries  and  two  words  of  the  activation 
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record  deleted  by: 

SWAP  l,n+4 
POP   2 

The  environment  of  the  caller  is  restored  by 

COPY  1 

LEFT 

SETEP 

leaving  the  stack  in  the  form: 

1 
2 


n+1 
n  +  2 


The  address  to  which  to  return  to  the  caller  is  extracted  from 
the  dynamic  link  and  saved  above  the  answer  in  the  stack  by: 

RIGHT 

SWAP  l,n+l 
POP   n 

The  'POP  n '  instruction  deletes  the  n  parameter  values,  exposing 
the  return-address  for  a  101  back  to  the  caller.  The  resulting 
code  is: 


OL 

Pn 

. 

PI 

answer 

— w^-*- 

Return  n   = 
SWAP  l,n+4 
POP   2 
COPY  1 
LEFT 
SETEP 
RIGHT 

SWAP  l,n+l 
POP   n 
GOI 

5   Conditionals 


}  save  answer 

}  delete  closure,  SL 

I 

}  restore  EP  from  DL 

I 

}  get  return  address  trom  OL 

}  save  return  address 

}  delete  parameters 

}  reenter  caller 


The  compiled  L-Code  for  handling  conditionals   will   operate 
similarly  to  the  Eval  interpreter.   That  is,  for 

[  B  *>  T  |  F  ] 

we  must  first  evaluate  B  and  if  it  is  true  evaluate  T,   otherwise 
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evaluate  F.   The  translation  to  accomplish  this  is: 

A(  [  B  ->  T  I  F  ]  ]   = 

AfB] 

IF  t 
A[F] 

COTO  x 
t:   ACT) 
x: 

<S   Blocks 


In  section  1.4.20  we 
(local   declarations)   co 
Eval  directly,  rather  tha 
true  with  respect  to  the 
simpler  activation  record 
will   not   be   necessary 
Indeed,  since  a  block  is 
definition,   its   static 
Further,  since  a  block  is 
is   not   necessary   to   s 
means  that  these  items  co 
tion   record   for   blocks 
the  format  will  aqree   wi 
record.    This   will  alio 
already  discussed  regardl 
a  procedure  or  a  block. 
use  two  different  formats 
translation  process. 


saw   that   the   ef 
uld   be  improved  by 
n  as  procedure  invoc 
L-Code  implementatio 
structure  will   suf 
to   construct   or 
always  invoked   in 
and   dynamic  links 
always  invoked  from 
ave  the  IP  of  the  ca 
uld  be  omitted  entir 
,  we  will  include  sp 
th   that   of   a   pro 
w  us  to  use  the  tran 
ess  of  whether  the  v 
In  an  actual  compile 
at  the  expense  of 


ficiency  of  blocks 
implementing  them  in 
ations.  The  same  is 
n  of  blocks,  since  a 
fice  and  since  it 
decompose  closures. 
its  environment  of 
are  always  the  same, 
the  same  place,  it 
Her.  Although  this 
ely  from  the  activa- 
ace  for  them  so  that 
cedure's  activation 
slation  of  variables 
ariable  was  bound  by 
r  we  might  choose  to 
a   more   complicated 


with  this  exolanation  done  we  can  proceed  with  the  transla- 
tion  of  blocks.  This  makes  use  of  two  "macro"  instructions  which 
create  and  delete  the  block's  activation  record: 


AClet  v1=ei  and 


Alei) 


Ate  ] 

Begin 
AtB] 
Fnd  n 


•  and  vn=en  in  B] 


The  Begin  and  5nd  instructions  are  simplifications 
Return: 


of   Call   and 


Begin   = 
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PUSHUP 


}  ep 


}  build  DL 


PUSHEP      }  SL 

MARK        }  install  new  current  AR 


End  n 


SWAP  1 , 3+n  I  save  answer 

POP   2      }  delete  first  local  and  SL 

}  restore  EP 
SETEP       }    from  DL 

POP   n-1    }  discard  rest  of  locals 
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